OODA Loop

Aunque el modelo de OODA Loop fue desarrollado para proyectos militares, se está aplicando en la actualidad como metodología de implantación de soluciones de gestión en tiempo real en las organizaciones.

El OODA Loop se compone de cuatro pasos: observación, orientación,
decisión y acción. La organización que sea capaz de recorrer el "Loop" en menos tiempo, es decir aquella que sea más ágil, alcanzará una ventaja competitiva. Por tanto la variable tiempo, es el centro de la estrategia en esta metodología.
  • El primer paso es el de observación. Se trata de llevar a cabo procesos de adquisición y comunicación de la información existente en el entorno.
  • El segundo paso es el de orientación. Es el más importante porque es en éste donde se analiza, entiende e interpreta la información que se ha recogido y tiene incidencia directa en los dos pasos siguientes. Durante esta fase se describe el entorno encontrado, se analizan las posiciones de los agentes y se abstraen los principales patrones de comportamiento, amenazas y oportunidades.
  • En el paso de decisión, se desarrollan diferentes planes de actuación partiendo de la información recogida y analizada en los pasos anteriores.
  • En el último paso, el de acción, se llevan a cabo los planes diseñados y se analizan los resultados obtenidos que son favorables, no favorables o indeterminados. Estos resultados son de nuevo observados y el ciclo comienza de nuevo.
Como en la mayoría de las metodologías y modelos propuestos para este tipo de entorno, los pasos propuestos no tienen por qué ser realizados siempre. Lo ideal es que exista un conocimiento previo y exhaustivo del entorno, por lo que no debería ser necesario realizar las fases de orientación y decisión. Pero todos sabemos que esto no siempre es así, por lo que en las organizaciones que decicen utilizar este modelo es recomendable empezar siempre por el principio y desarrollar por completo los cuatro pasos.


¿Qué es PRINCE2?

PRINCE (PRojects IN Controlled Environments) o proyectos en entornos controlados es un método estándar para la gestión efeciente de proyectos. PRINCE fue desarrollado por la CCTA (Central Computer and Telecommunications Agency) y en su primera versión se basa en otro método de gestión de proyectos llamado PROMPTII al que PRINCE sustituye en 1989 como el estándar utilizado en todos los proyectos de sistemas de información del gobierno británico.

Es en 1996 cuando se publica la versión de PRINCE2, que además de mejorar la versión anterior, se convierte en un método genérico para la gestión de proyectos, válido para todos los entornos, no solo para proyectos TIC (Tecnologías de Información y Comunicaciones) de la Administración Pública.

Actualmente PRINCE2 es un estándar de facto ampliamente usado por el gobierno del Reino Unido y muy reconocido y utilizado en el sector privado británico. Poco a poco, su uso también se está haciendo importante en los países de la Commonwealth y de forma más discreta en el resto de Europa.

La última versión de PRINCE2 es del año 2009 y en ella se estructura el método en cuatro partes: temas (en la versión del 2005 se denominaban componentes), procesos, técnicas y roles.

Los temas son áreas de conocimiento que deben aplicarse al proyecto cuando corresponda. Son 7 y entre ellos se encuentran los procesos de negocio, organización, calidad, planes, riesgo,
control del cambio y progreso.

Estos temas son implementados mediante los procesos, que son los elementos que explican qué debe ocurrir y cuándo a lo largo del ciclo de vida del proyecto. Se definen 8 procesos entre los que se encuentran los de comenzar un proyecto, iniciarlo, dirigirlo, controlar una fase, la gestión de suministro de producto, la gestión del límite de las fases y el cierre del proyecto.

Además existen 40 subprocesos asociados a los procesos que constan de sus correspondientes acciones normativas.

Las técnicas ofrecidas son métodos de trabajo de uso opcional que PRINCE2 recomienda. Estas son la planificación basada en producto (Product-based planning) y la revisión de la calidad (Quality review).

Por último se definen hasta un total de 10 tipos de roles que pueden intervenir en un proyecto. Algunos ejemplos son: el jefe de proyecto, el jefe de equipo, el responsable de soporte, el
usuario, etc.

Criterios de selección de un socio tecnológico

Cuando es necesario desarrollar un proyecto contando con la intervención de un integrador de sistemas o ingeniería, los clientes finales tienen dudas acerca de cuáles son los criterios que deben seguirse para llevar a cabo una correcta selección que asegure el éxito del proyecto.

En esta entrada, damos algunas recomendaciones para realizar una correcta elección del socio tecnológico que facilite el desarrollo del proyecto.

  • Realizar la selección de forma directa, sin la inclusión de agentes externos.
  • Contratar una compañía que tenga un tamaño semejante (recursos, facturación) a la organización en la que se va a desarrollar el proyecto.
  • Seleccionar un socio tecnológico que pueda probar su conocimiento y experiencia en proyectos similares (utilizando las mismas tecnologías y conociendo el mismo tipo de procesos) y que pueda demostrar que las personas que van a participar en el proyecto son las adecuadas para llevar a cabo la implantación. Es decir, esto evitará o disminuirá la posibilidad de que se lleve a cabo la subcontratación de las tareas de implantación por parte del socio tecnológico a una empresa tercera.
  • Contar con socios tecnológicos que cuya gestión interna sea avalada por certificados de calidad.
  • Apostar por socios tecnológicos que además de conocimientos técnicos tengan conocimientos suficientes para realizar una gestión integral del proyecto y si es posible con experiencias en organizaciones pertenecientes al mismo sector.
  • Contar con socios que puedan probar su solvencia financiera y su permanencia en el mercado a medio/largo plazo.

Recomendación. Blog Héctor Montenegro.

Os dejo este enlace para los que no conozcáis el blog de Héctor Montenegro (NTO de Microsoft Ibérica):

http://blogs.technet.com/hectormontenegro/archive/2009/12/09/10-razones-para-no-elegir-software-de-fuentes-abiertas-en-la-educaci-n.aspx


Aunque os recomiendo el blog en general, este enlace os lleva a una entrada que me ha parecido muy interesante ya que se da un punto de vista distinto al expuesto en el informe titulado “10 Razones para elegir Software de Fuentes Abiertas en la educación” de la
Fundación CENATIC (http://www.cenatic.es/).

Aunque la discusión se centra en los proyectos Escuela 2.0, seguro que todos vosotros podéis extrapolar muchos de los argumentos expuestos en un sentido y en otro a vuestros propios entornos, ya que se trata de la eterna discusión también en el sector industrial.
aa

Gestión de proyectos (y II)

La gestión de proyectos ha evolucionado durante los últimos años, convirtiéndose en una disciplina utilizada habitualmente en toda iniciativa en la que exista un grupo de trabajo que tiene que
realizar una serie de actividades con el propósito de alcanzar un determinado resultado. Existe multitud de bibliografía, así como diferentes enfoques y metodologías que ayudan a realizar una gestión de proyectos eficiente. Independientemente de sus rasgos diferenciales, todos
estos enfoques y metodologías deben considerar que la base de la gestión de proyectos consiste en optimizar o manejar de forma óptima las siguientes tres restricciones: necesidades, tiempo y
coste.

  • La correcta definición de las necesidades que debe cubrir un proyecto, se realiza a través de las especificaciones de proyecto. Estas especificaciones pueden no ser óptimamente satisfechas por diferentes motivos: falta de comunicación entre las partes implicadas, desequilibrio entre las expectativas creadas por parte del cliente, errores en la definición de necesidades, errores en las actividades de ejecución del proyecto, etc.
  • El tiempo se gestiona óptimamente realizando una buena planificación temporal de las actividades que hay que desarrollar para cubrir las necesidades. Entre las causas que pueden provocar que la planificación temporal no se realice en las fechas especificadas se encuentran: la falta de recursos para realizar determinadas actividades (que provocan por tanto retrasos en el desarrollo del proyecto), la dedicación parcial (no comprometida) que llevan a cabo los recursos asignados para el desarrollo de las tareas de proyecto o la aparición de nuevas funcionalidades no contempladas en la especificación inicial.
  • El coste implica realizar estas actividades con los recursos y presupuesto inicialmente establecidos. Esta restricción puede desviarse también por diferentes motivos: mal uso de los recursos disponibles, asunción del desarrollo un proyecto por un coste inferior al inicialmente determinado (teniendo en cuenta su alcance real), estimaciones iniciales de coste optimistas, etc.m

Información mantenida por el sistema operativo

Prácticamente todos los sistemas operativos actuales mantienen información sobre las diferentes tareas que se están ejecutando en el sistema y sobre la utilización que se está haciendo de sus recursos. El otro día uno de vosotros me preguntaba si esa información es fiable para hacer una evaluación de rendimiento exhaustiva del sistema.

La respuesta es afirmativa. Aunque la finalidad de mantener esta información no es proporcionar una herramienta de medida de rendimiento, el sistema de información del SO realiza funciones similares a las de cualquier monitor. La información típica que suele mantener el SO incluye la utilización de la CPU y de la memoria, el número de tareas en el sistema, el tiempo de inicio y de finalización de cada tarea, el tiempo que cada tarea ha pasado realmente en el procesador, etc. Hay que tener en cuenta que el sistema operativo no suele mantener información acerca de la longitud de las colas de ejecución de los distintos recursos (no sólo del procesador), del número de eventos relacionados con las funciones de E/S o del número de cambios de contexto, sólo por poner algunos ejemplos.

La principal ventaja de utilizar este tipo de información es que no hace falta desarrollar código específico para realizar las medidas de rendimiento, pero la principal desventaja es la sobrecarga que el acceso a esta información mantenida por el sistema operativo puede suponer para el sistema dependiendo de la frecuencia con la que se realice.

Gestión de proyectos (I)

El Project Management Institut (PMI) define la gestión de proyectos (project management) como la aplicación de conocimientos, habilidades, herramientas y técnicas que permiten planificar, organizar y gestionar recursos materiales, tecnológicos y/o humanos, con el fin de obtener eficientemente (en términos de alcance, tiempo y coste) los objetivos generales y específicos establecidos en un proyecto.

Además de esta definición propuesta por el PMI (Project Management Institute), otras organizaciones como la American Society for the Advancement of Project Management, la Global Alliance for Project Performance Standards o la PMForum , tienen como propósito principal, estandarizar y difundir los conceptos asociados a la gestión de proyectos así como las mejores prácticas realizadas en distintos sectores y tipologías de proyecto.

La gestión de proyectos tiene sus orígenes en los trabajos realizados principalmente por Henry L. Gantt. De este autor se destacan dos obras, "Work, wages, and profits" y "Organizing for Work" en las que se recoge una herramienta básica que sigue siendo hoy utilizada para la gestión de proyectos que es el diagrama de Gantt.

Este diagrama permite identificar todos los
grupos de tareas, tareas individuales e hitos establecidos para desarrollar un proyecto, asignándoles un tiempo previsto de dedicación. Es una herramienta que permite analizar fácilmente la relación existente entre la carga de trabajo asignada y el tiempo previsto para completar dicha carga.

Este diagrama propicia la aparición de otras herramientas de gestión de proyectos como los CPM (Critical Path Method) o los grafos PERT (Program Evaluation and Review Technique), en los que, a diferencia del de Gantt, las actividades y recursos tienen relaciones de dependencia entre sí y en ambos casos, se persigue calcular la ruta crítica del proyecto y sus holguras.

Es decir, teniendo en cuenta estas
dependencias, ambas técnicas son utilizadas para determinar el tiempo más corto en el que es posible completar el proyecto. Existe una ruta crítica y rutas alternativas para ejecutar todas las actividades. La diferencia de tiempo entre la ruta crítica y el resto de rutas, es lo que se define como holgura, siendo nula para la ruta crítica.
aa
m

Imagen de Sistema Único

Ya hemos comentado en entradas anteriores que las arquitecturas de memoria distribuida tipo cluster o grid tienen que utilizar comunicación explícita entre procesos y suelen presentar dos problemas: la falta de imagen de sistema único y la dificultad de equilibrar la carga de trabajo.

Para solucionar el problema de la falta de imagen de único es necesario instalar un middleware sobre el sistema operativo local instalado en cada uno de los nodos que componen el sistema o parchear/modificar estos sistemas operativos locales para que funcionen como un sistema operativo distribuido.

En cualquiera de los dos casos, la intención es proporcionar una capa intermedia entre los usuarios y sus aplicaciones, además, la imagen de sistema único se favorece si existe un punto de entrada único a la arquitectura y un punto de control y gestión de la arquitectura también único. Pero es necesario que esa capa intermedia proporcione los siguientes servicios:
  • Espacio de procesos único.
  • Sistema de planificación de trabajos único.
  • Sistema de ficheros único.
  • Espacio de E/S único.
  • Interfaz de usuario único.
Y todavía no existe ninguna herramienta que permita, tanto al administrador como a los usuarios, ver una arquitectura de memoria distribuida como un sistema de cómputo único fuertemente acoplado, aunque cada vez nos acercamos más.
aa

System Platform 3.1. Arquitecturas distribuidas y Centros de Control

System Platform permite desarrollar aplicaciones distribuidas utilizando una sóla licencia. Es decir , el modelo lógico de objetos es totalmente independiente del modelo Hardware. Una vez que se desarrolla la aplicación (objetos + modelo), se decide sobre que plataforma hardware se instala. El software no está ligado a un Hardware (los objetos podrán ejecutarse en cualquier PC conectado a la Red).
n
Es importante señalar que System Platform puede ejecutarse también en un MONOPUESTO. No es necesario desplegar una arquitectura distribuida de aplicación. Depen
diendo del tamaño de la aplicación, se verá la conveniencia de ejecutarlo de manera más o menos distribuida.

El no estar ligado a una Arquitectura fija, ya que los objetos pueden distribuirse sobre cualquier PC, hace que el proyecto asuma la característica de alta disponibilidad. Es decir, se puede desarrollar una nueva funcionalidad de la aplicación y luego ponerla en marcha, sin que el sistema deje de funcionar. Solo se tendrán que ejecutar los nuevos objetos desarrollados.
n
Esta independencia hace que en caso de que un determinado servidor pudiera estar saturado, lo único que se debe hacer es, desde la herramienta de desarrollo, hacer que una s
erie de objetos se ejecuten en otro servidor. Desde el punto de vista de visualización, control y recolección de históricos, este proceso de distribución de cargas es transparente.
n
El mercado está demandando la capacidad de Desarrollar Salas de Control de entornos distribuidos de forma sencilla. Esta sala de control debe tener la capacidad de permitir que la aplicación sea desarrollada tecnológicamente desde un único sitio (en este caso llamamos aplicación a desarrollo de Software, Instalación de Drivers de forma remota, Mantenimiento de Hardware…) y además permita a un usuario visualizar y controlar de una forma operativa, toda esa aplicación desarrollada.
n

Del mismo modo, este desarrollo remoto, no debe estar condicionado a potentes comunicaciones. Se debe tener la capacidad de realizar este desarrollo y este mantenimiento con redes de banda baja (a nivel MODEM). La creación de centros de control con System Platform se realiza de forma eficiente gracias a las características de su tecnología:

  • Posibilidad de contar con una licencia corporativa que sea desplegada entre diferentes plantas o infraestructuras (desde 250 señales hasta 1.000.000). System Platform permite la posibilidad de utilizar la solución System Platform Single Node para utilizar una sola máquina para el despliegue de objetos.
  • Crear un centro de control de forma modular. Por ejemplo, comenzando con la consolidación de datos de proceso o instalaciones en un repositorio único, para luego hacer una visualización y control conjunta vía sinópticos, para terminar con la introducción de funcionalidades MES, gestión eficiente de recursos energéticos o integración con herramientas de mantenimiento.
  • Capacidad para tomar datos de diferentes SCADA´s y dispositivos de campo (vía OPC, mediante drivers, conversores, gateways, etc).
  • Administrar de forma centralizada, tanto a nivel usuario final, como a nivel desarrollo toda la aplicación.
  • Utilizar la tecnología Terminal Services para acceder de forma remota a las instalaciones de forma concurrente.
  • Una problemática habitual consiste en la necesidad de tener datos históricos locales para luego agrupar estos datos en un histórico central. Es decir, distribuir varios Históricos en plantas locales para que estos datos se consoliden en uno central de forma automática. La plataforma incluye la opción de Tier Historian que facilita la integración de Historian distribuidos en un Historian Central.
n

Procesadores VLIW

Los procesadores Very Long Instruction Word (VLIW, Palabra de Instrucción Muy Larga), estuvieron unos años casi en desuso pero han vuelto a estar de actualidad porque han inspirado el diseño de las arquitecturas como la del Itanium (arquitectura EPIC), que han resuelto la mayor parte de los problemas que presentaban los antiguos diseños VLIW.

En este tipo de arquitecturas el compilador empaqueta un conjunto instrucciones que pueden ejecutarse en paralelo en una única instrucción muy larga. Es decir, el compilador especifica explícitamente el paralelismo en cada instrucción, no es una responsabilidad del procesador. Para mantener todas estas unidades funcionales del procesador ocupadas, el paralelismo inherente al código tiene que ser alto. Es habitual utilizar técnicas que lo aumenten como el desenrollado de bucles, la reordenación del código, la ejecución de predicados, etc.

El principal problema de este tipo de arquitectura ha estado tradicionalmente en el tamaño de los códigos, ya que en cada instrucción suelen quedar huecos al ser imposible empaquetar siempre sub-instrucciones que rellenen palabras de instrucción muy largas por completo debido a los riesgos. Estos huecos ocupan espacio en la memoria innecesariamente.

Además, existen problemas de compatibilidad entre diferentes arquitecturas. Incluso entre diferentes implementaciones de la misma arquitectura (una nueva unidad funcional ó una latencia diferente para alguna de las unidades, por ejemplo), sería necesario recompilar el código para planificar adecuadamente las sub-instrucciones.

Los procesadores VLIW han sido una buena opción para el diseño de sistemas empotrados, ya que consiguen la emisión múltiple de instrucciones con menor consumo de potencia que otro tipo de diseños en los que la responsabilidad de la planificación recae sobre el hardware. Pero no se han utilizado mucho en otro tipo de sistemas, en los que se ha comprobado que cuando un procesador VLIW puede conseguir un rendimiento alto, también puede hacerlo casi siempre un procesador vectorial, con un diseño de compilador y del propio procesador bastante más sencillo.

aaa

Wonderware. Opciones de visualización, control y gestión de la información

Durante mis últimas reuniones me he encontrado con el problema de tener que explicar a algunos integradores y clientes finales, las diferentes opciones de visualización, control y gestión de la información que Wonderware proporciona.

Las siguientas tablas tienen como fin facilitar información acerca del tipo de funcionalidad y tipo de acceso que incluyen las diferentes soluciones Wonderware.

Podéis bajaros este documento accediendo a este link: Opciones de visualización, control y gestión de la información proporcionadas por Wonderware.

Evento. ANACAP 2009.

Los días 19 y 20 de Noviembre se celebra en la Universidad Rey Juan Carlos de Madrid (Campus de Móstoles), el segundo Workshop en Aplicaciones de Nuevas Arquitecturas de Consumo y Altas Prestaciones.

El ANACAP surgió el año pasado con la idea de ser un punto de encuentro de investigadores nacionales que usen estas tecnologías para acelerar sus soluciones algorítmicas, así como un foro para promover e incentivar nuevas propuestas de cómputo optimizado para diferentes aplicaciones, visión artificial y procesamiento de imagen especialmente.

Ya sabéis que además de las presentaciones de los artículos admitidos en esta edición, y de las presentaciones realizadas por las empresas patrocinadoras, por las tardes hay programados tutoriales muy interesantes acerca de GPGPU y CUDA, programación con OpenMP y programación del procesador Cell de la consola PlayStation 3.

Os dejo en enlace a la web del congreso por si queréis consultar el programa:

http://www.gavab.es/capo/anacap/index.html
aa

Actionable Enterprise Architecture (AEA)

El concepto de Enterprise Architecture (EA) define los procesos, entradas, infraestructura tecnológica, componentes software, servicios y roles que permiten conseguir los objetivos estratégicos de la organización. Esta arquitectura también debe definir las relaciones y jerarquías entre todas estas partes involucradas en el negocio.
m
En EA se definen cuatro categorías de elementos reutilizables:
  • Arquitectura estratégica. En la que se incluye la visión, los objetivos organizativos y los planes estratégicos y operativos que permitan alcanzar dichos objetivos.
  • Arquitectura de negocio. Entendiendo este elemento como el conjunto de productos, servicios, capacidades, roles y localizaciones de la organización.
  • Arquitectura de sistemas. Incluyendo los procesos de negocio, sistemas de información y personas que soportan el desarrollo de la arquitectura de negocio.
  • Arquitectura tecnológica. Siendo este elemento el conjuntode dispositivos hardware y soluciones software sobre las que se ha desarrollado la arquitectura de sistemas.

El modelo de gestión AEA (Actionable Enterprise Architecture) permite alcanzar los objetivos organizativos en tiempo real, gestionando eficientemente los procesos de negocio, cuyas actividades son ejecutadas por sistemas de información.

m

RAM estática vs RAM dinámica

En alguna ocasión me habéis preguntado por la diferencia entre una memoria RAM estática (SRAM) y una memoria RAM dinámica (DRAM), ya que os habéis encontrado con estos términos en las especificaciones de un sistema. Intentaré aclararlo en esta entrada con conceptos muy sencillos.

Las memorias RAM (Random Access Memory) son aquéllas que permiten acceder a una posición aleatoria de la memoria para leer o escribir en ella sin necesidad de acceder previamente a todas las anteriores. Es decir, se puede indexar directamente la fila y la columna en la que está almacenada la información a la que se desea acceder ya que los datos se almacenan en estas memorias en forma de matriz.

La diferencia entre una RAM estática y una RAM dinámica está en la tecnología que se utiliza para construirla. En una RAM estática son necesarios 6 transistores para almacenar 1 bit de información, mientras que en una RAM dinámica son necesarios 1 transistor y 1 condensador. Es decir, mucha menos lógica, por eso en el mismo área de una DRAM cabe más información que en una SRAM.

Entonces, ¿por qué se utiliza la tecnología SRAM?. Principalmente por dos motivos. Al estar fabricada sólo con transistores, se puede integrar en el mismo chip que un procesador, por ejemplo, construido también sólo con transistores.

Pero, el principal motivo es que es una memoria mucho más rápida que la DRAM ya que no necesita ciclos de refresco. La información almacenada en una celda SRAM no se pierde con el tiempo, sin embargo, la almacenada en una celda DRAM sí, ya que el condensador se descarga con el tiempo. Esto obliga a invertir tiempo en leer lo que está almacenado en la memoria antes de que los condensadores se descarguen y a reeescribirlo para que la información no se pierda (refresco), lo que ralentiza el funcionamiento de la memoria.

Para que tengáis un ejemplo que os resulte familiar, en las jerarquías de memoria que incorporan los PCs y los portátiles, se utiliza SRAM para la memoria caché (integrada con el procesador, pequeña y muy rápida) y DRAM para la memoria principal (en otro circuito externo, de mayor capacidad y más lenta).
yy

Evento. DISI 2009.

El DISI 2009, en su cuarta edición, se celebrará el lunes 30 de noviembre de 2009 a partir de las 09:00 en el Salón de Actos del Campus Sur de la UPM, Universidad Politécnica de Madrid.

Se trata del Día Internacional de la Seguridad de la Información, que se lleva celebramdo desde el año 1988. En esta edición un prestigioso investigador de IBM Research Estados Unidos abrirá el evento con la conferencia Randomized Hashing: Secure Digital Signatures without Collision Resistance (en castellano). A continuación se celebrarán dos coloquios, el primero sobre Tndencias en el Malware y el segundo sobre Mitos y Realidades en Hacking. El evento terminará a las 15.00.

La asistencia al evento es totalmente gratuita previa inscripción en

www.capsdesi.upm.es

O por teléfono contactando con Beatriz Miguel en el número 913367842.
tt

System Platform 3.1. Niveles de Redundancia

System Platform contempla la posibilidad de incluior varios niveles de redundancia y alta disponibilidad a los proyectos. Estos niveles son:
  • Redundancia a nivel comunicaciones.
  • Redundancia a nivel aplicación.
  • Alta disponibilidad de históricos.
  • Redundancia a nivel de interfaz de visualización y control.

Redundancia a nivel comunicaciones. System Platform incluye el objeto Redundan Device Integration Object (RDI Object). En caso de que un PLC tenga dos redes de comunicación disponibles, si un canal falla el RDI Object permite conmutar automáticamente a la otra red, evitando la pérdida de comunicación.

Redundancia a nivel aplicación. System Platform incorpora un sistema de Redundancia automática. Es decir, no es necesario desarrollar un Scripting específico para esta funcionalidad, sino que solo se tendrá que activar la redundancia en el objeto "engine" para que esté operativa.

Desde el punto de vista de licencias software, esta activación es transparente a nivel objetos.

Desde un punto de vista económico es importante señalar que la redundancia a nivel Software es una funcionalidad más incluida en la licencia de System Platform. Es decir, no es necesario la adquisición de una "Licencia Redundante" para activarla. Solo se necesita un elemento Hardware adicional (un servidor).

La redundancia funciona de la siguiente manera. Existen dos servidores, uno primario y otro esclavo. Los servidores ejecutan al mismo tiempo todas las operaciones (es decir, se realiza un despliegue doble de objetos) que permiten que la aplicación esté en marcha. Se almacenan históricos y registros de alarmas, se gestionan las comunicaciones con la Red de Campo, se gestiona la configuración de seguridad, se gestiona el funcionamiento de la aplicación.

Si el servidor primario cae, automáticamente (en caliente) el servidor esclavo toma el control de la aplicación sin perder datos y aportando alta disponibilidad a la aplicación. Una vez que el primario se recupera, los dos servidores vuelven a funcionar simultáneamente.

Desde el punto de vista de desarrollo, la redundancia se activa a través de un “clic”. Es decir no hay que desarrollar código a medida para llevarla a cabo. Esto hace que la aplicación sea muy robusta. Es la propia plataforma software la que facilita esta funcionalidad y no el código desarrollado para una aplicación específica.

System Platoform permite aprovechar la redundancia para realizar balanceo de cargas. Es decir, se podrían utilizar los dos servidores para repartir la carga Ej. el 70% de los objetos corren en el servidor activo y el 30% en el esclavo, y configurar la redundancia para que cualquiera de los dos hiciera de backup en caso de caída de uno de ellos.

Alta disponibilidad de históricos. En cuanto a la redundancia de históricos, se recomienda que el servidor de Base de Datos se configure de forma independiente de los servidores de objetos.

Los objetos recogen la información y esta información se almacena en la Base de Datos.

Si el Servidor de Base de datos cayera, el propio objeto sería el que recogería la información y la almacenaría como buffer en el disco duro del servidor de objetos. Tras recuperarse, enviaría estos datos al servidor de históricos. Es decir, el propio sistema incorpora de esta manera una forma de redundancia de históricos embebida en la propia configuración de los objetos.

Se asegura que en ningún caso, se pierdan datos.

Redundancia a nivel de interfaz de visualización y control. La solución que se propone se basa en arquitecturas Terminal Services. En un servidor con sistema operativo servidor Windows se instalan sesiones (InTouch for SP for Terminal Services) que permiten la visualización y control de los procesos. (NOTA: En este servidor deberán instalarse también las licencias de MS Terminal Services).
m
El acceso a este servidor, y por tanto a las sesiones, se realiza desde el escritorio remoto que Windows incorpora de forma estándar. Las sesiones terminal services podrán ser por usuario logado o bien concurrentes. En paralelo se activa otro servidor en el que se instalan las mismas sesiones (en este caso Wonderware hace un descuento del 80% sobre el precio de las licencias). Si el servidor primario cae, el operario puede redirigir su petición al servidor secundario, haciendo así que en ningún caso se pierda visibilidad sobre el proceso.


m

Multithreading

Ya hemos comentado en alguna entrada anterior que la mayor parte de las técnicas de optimización de procesadores actuales se basan en intentar aprovechar al máximo los recursos hardware del procesador ejecutando diferentes instrucciones en paralelo (ILP o paralelismo a nivel de instrucción).

En ocasiones no es posible explotar el paralelismo a nivel de instrucción dentro de un proceso debido a las dependencias que existen entre unas instrucciones y otras y que impiden su ejecución paralela. Una posible solución es el multithreading, que permite explotar el paralelismo entre instrucciones que pertenecen a diferentes hilos de ejecución o threads, y que por lo tanto es menos probable que dependan unas de otras (TLP o paralelismo a nivel de thread).

A diferencia de la mayor parte de las técnicas de ILP, el multithreading involucra directamente al sistema operativo y al compilador. Si una aplicación no está compilada para ejecutarse en diferentes threads y/o el SO no soporta este tipo de ejecución, no nos valdrá de nada que el procesador incorpore esta técnica.

El multihtreading consiste en ejecutar al mismo tiempo dos o más threads de un programa, permitiendo que cada uno de estos threads sea planificado de la manera más conveniente en el procesador, es decir, aprovechando al máximo todos los recursos disponibles. Es equivalente a tener dos o más procesadores lógicos o virtuales en lugar de uno sólo.

Hasta ahora la técnica de multithreading más utilizada ha sido el SMT (Symmetric MultiThreading) o Hyperthreading, patentado por Intel. Consiste en permitir que se emitan en el mismo ciclo instrucciones que pertenecen a distintos hilos de ejecución o threads. De momento todas las implementaciones han permitido ejecutar simultáneamente instrucciones de 2 threads diferentes, lo que permite aprovechar recursos que de otra manera no se utilizarían.

Físicamente sólo se tiene un procesador, aunque virtualmente es como si se tuvieran dos. Para que os hagáis una idea, con dos threads (dos procesadores virtuales), se puede incrementar el rendimiento del procesador en un 25 ó 30%, obviamente no en un 100%, ya que casi todos los recursos hardware son únicos y se comparten entre los dos threads.
aa

Gestión eficiente de recursos energéticos (y III)

El material utilizado para redactar estas entradas ha sido proporcionado por la Ingeniería Consultora Enco, quien ha incorporado una línea de negocio dirigida a aportar soluciones para la gestión energética (encoEnergy).
m
Para más información acerca de las actividades desarrolladas por Enco en este ámbito, se adjuntas los datos de contacto:


http://www.encoweb.com/

Manuel Guil

-------------------------------------------------------
Entradas relacionadas:


Los requerimientos generales que debe cumplir un sistema de gestión energética son estos:

  • Herramientas de monitorización. Herramientas de monitorización, comparación y previsión por tipo de servicio.
  • Facilidad de configuración. Informes (reports) y paneles de indicadores (Cockpit).
  • Sistema intuitivo. Herramientas de análisis intuitivo para la mejora de la eficiencia.
  • Conversión de consumos. A gasto (euros) y a emisiones (CO2).
  • Escalabilidad. Facilidad de añadir nuevos dispositivos de medición, de crear nuevos reports, etc.
  • Capacidades de previsión. Realizar previsiones de consumos energéticos futuros.
  • Integración. Comunicación completa con sistemas existentes.


En cualquier caso, una organización no debe plantearse un proyecto de gestión eficiente de recursos enérgeticos a no ser que su factura mensual por concepto de consumo energético supere los 100.000€.

Además hay que tener en cuenta, que el ahorro esperado al realizar con éxito este tipo de proyectos se cuantifica entre un 5% y un 10% sobre la cuota defacturación inicial.

Este beneficio de tipo cuantitativo, se complementa con otros beneficios de caracter más cualitativo:

  • Conocimiento exácto de consumos.
  • Mejor asignación a centro de costes.
  • Imagen de la empresa si es posible comunicar que ha reducido emisiones.
  • Cumplimiento de normativas de calidad mediambiental.
  • Capacidad para informar a las ESCO (Energy Service Company) de la previsión de consumo energético.

m

Gestión eficiente de recursos energéticos (II)

El material utilizado para redactar estas entradas ha sido proporcionado por la Ingeniería Consultora Enco, quien ha incorporado una línea de negocio dirigida a aportar soluciones para la gestión energética (encoEnergy).

Para más información acerca de las actividades desarrolladas por Enco en este ámbito, se adjuntas los datos de contacto:



http://www.encoweb.com/
Manuel Guil
m.guil@encoweb.com
-------------------------------------------------------



Uno de los principales instrumentos utilizados para realizar una gestión eficiente de recursos energéticos es la utilización de sistemas de gestión energética.
m
Los sistemas de gestión energética son soluciones software que a partir de la supervisión, control y captura de información en tiempo real de diferentes dispositivos de campo (contadores, caudalímetros), asociados a la medición de fuentes energéticas (normalmente gas, electricidad, y conversiones de agua fría a agua caliente y viceceversa, generación de vapor, etc), permiten reducir los costes energéticos y minimizar las emisiones.
m
Esto se materializa en las siguientes ventajas:
  • Reducen y controlan los picos de demanda.
  • Reducen las emisiones de CO2.
  • Optimizan las condiciones con los suministradores de energía.
  • Realizan asignación de costes.
  • Ayudan a tomar decisiones.


Los sistemas de gestión energética deben incluir las siguientes funcionalidades:

  • Gestión de consumos. A través de informes predefinidos para los diferentes tipos de energías, el usuario puede conocer los consumos, analizarlos y visualizar los principales indicadores de gestión energética. Esta práctica es lo que se conoce como el alisamiento de la curva de consumo. El hecho de conocer los consumo históricos de energía, proporciona a la empresala posibilidad de realizar un consumo más estable, sin que se produzcan picos que penalizan la facturación total. Esta gestión también posibilita la asignación de costes energéticos a centros de costes.
  • Balance energético. Supervisión de la carga principal así como de las subáreas, control de la carga pasiva y activa, agregación de multi-instalación y control de picos en la demanda eléctrica de cada instalación.
  • Emisiones. Conversión de consumos a emisiones CO2.
  • Forecasting. Módulo básico para identificar tendencias o previsiones de consumos futuros. En este sentido, es básico contar con una solución que recoja todaesta información en tiempo real y sin extrapolaciones ni aproximaciones.
  • Billing y Costes. Verificación de la facturación , asignación de costes y simulación. Esta funcionalidad permite que las empresas corroboren que la facturaemitida por el proveedor de energía es correcta. En ocasiones existen desviaciones de hasta un 5%.Este módulo debe permtir la integración con tarifas (para permitir esta comparación). Estas tarifas generalmente están localizadas en el ERP de las organizaciones.

v


Reunión Técnica. Tecnología OPC.

El próximmo 4 de noviembre de 2009 la sección española de ISA organiza en Madrid (en la Facultad de Matemáticas de la Universidad Comlutense) una reunión técnica acerca de tecnología OPC. El día 5 se celebrará la misma reunión en Barcelona.

En esta reunión se analizará brevemente qué es OPC, sus especificaciones y los beneficios de su uso. En concreto, en la primera parte se tratarán los siguientes temas:
  • Requerimientos de estandarización en la conectividad industrial. Ejemplo practico de la solución OPC.
  • Presentación de las principales especificaciones existentes dentro del estándar OPC: OPC DA, OPC DHA, OPC A&E, OPC UA.
  • Beneficios obtenidos en la implementación de un estándar de conectividad en el entorno industrial.
En la segunda parte se realizará una mesa redonda y coloquio, con la participación de expertos en el tema (entre los que se encuentra Fernando Sevillano) y turnos de preguntas por parte de los asistentes.

La inscripción es gratuita:

http://www.isa-spain.org/actividad.asp?id=176
aa

La arquitectura hardware de Google

Ya hemos hablado en entradas anteriores de la buena relación coste/prestaciones de los sistemas de tipo cluster, y hemos comentado la posibilidad de diseñar arquitecturas realmente potentes incluso a partir de componentes obsoletos y completamente heterogéneos.

Como demostración para los "incrédulos", vamos a hablar hoy de la arquitectura que soporta el motor de búsqueda de Google, un cluster. Las consideraciones iniciales que los diseñadores de Google se hicieron estaban relacionadas con fiabilidad, la productividad y la relación precio/prestaciones. Debían conseguir una arquitectura con estas características que permitiera la ejecución de una aplicación programada en C/C++ y que se ejecuta sobre plataformas con Linux con replicación en como mínimo, tres puntos geográficos.

Para ello han construido un cluster a medida completamente heterogéneo y muy escalable. En cifras, cada tres meses se actualiza alguno de los componentes de los nodos de cómputo (procesador, memoria o disco) y entre un 2 y un 3% de los nodos son sustituidos cada año.

Los nodos de cómputo están agrupados en racks que contienen entre 40 y 80 nodos dcada uno. Hay cerca de 1000 racks en la actualidad, con nodos x86, desde Celeron a 533 MHz hasta biprocesadores Pentium IV. Cada nodo tiene enstre 256 MB y 1 GB de memoria DDR y 80 GB de capacidad de almacenamiento.

El cluster utiliza Gigabit Ethernet (cobre, cables de categoría 5) para la conexión entre los nodos, y los enlaces a Internet tienen un ancho de banda mayor (2 Gb/s en media).

Todos los nodos tienen instalado un sistema operativo Linux y herramientas a medida para instalación y actualización de software, para la monitorización (en media se reinician al día 20 nodos en remoto) y para la gestión del Google File System (GFS).

Como podéis observar no se ha realizado una inversión excesivamente alta en la plataforma hardware que soporta el sistema, sino que se aprovechan todo tipo de nodos de cómputo que todavía pueden servir en una arquitectura de este tipo aunque individualmente ya estén obsoletos. Sin embargo se ha conseguido un sistema independiente de fabricantes HW y SW, y que proporciona las prestaciones adecuadas para la ejecución de la aplicación.
aaa

Primer paso para la gestión de riesgos corporativos

Ya hemos introducido el concepto de ERM en entradas anteriores desde un punto de vista general.

Si nos interesa ponernos manos a la obra, existen diferentes metodologías, mejores prácticas y normativas que nos ayudan a afrontar la gestión de riesgos de una manera sistemática. Y casi todas ellas coindicen en comenzar por una primera fase de Identificación de riesgos.

El primer paso para la gestión de riesgos corporativos debe ser siempre realizar un inventario con todos los riesgos posibles. Y a ser posible, crear una base de datos de riesgos que sirva como base para toda la estrategia ERM de la organización.

Para realizar esta identificación se pueden utilizar diversos métodos:
  • Estadísticas e históricos del pasado.
  • Opiniones de expertos.
  • Experimentos, pilotos.
  • Simulaciones.
  • Análisis técnicos.
  • Brainstorming, cuestionarios.
  • Lecciones aprendidas.
  • Herramientas BPM (Business Process Management).
Y si ya sabemos cómo podemos identificar riesgos, la siguiente pregunta sería ¿dónde los buscamos?. Si intentamos comenzar por una clasificación universal, que no dependa de nuestro sector de actividad, una estrategia ERM completa debería tener en cuenta los siguientes riesgos:
  • Externos: Económicos, Medioambientales, Políticos, Legales, de Mercado y Sociales.
  • Internos: Financieros, Operacionales y Tecnológicos.
Pensando en estas categorías, ¿cuáles serían los más importantes para vuestra empresa?. ¿Por dónde empezar con la gestión de riesgos en una primera aproximación?.
ss

Introducción a Cloud Computing

Este concepto es cada vez más conocido, ya que se trata de un modelo de computación que permite a las organizaciones ahorrarse inversiones en aplicaciones, sistemas e incluso personal.

La idea principal es sencilla: que los clientes puedan acceder a recursos software y hardware ofrecidos como servicios a través de Internet. Ya en los años 90 Sun intentó comercializar clientes "finos" que utilizaran recursos ofrecidos a través de la red para realizar la mayor parte de las tareas.

Pero no ha sido hasta estos últimos años, con la madurez de las arquitecturas orientadas a servicios (SOA), cuando este modelo de computación se ha comenzado a ver como una realidad.

Normalmente se distinguen tres categorías de sistemas Cloud:
  • Software as a Service (SaaS): En este caso el cliente paga por la utilización de un software, y tanto el código de la aplicación como los datos se almacenan en remoto. Esta es la categoría más extendida hoy en día, todos conocemos casos de organizaciones que utilizan Google Docs o algún CRM que no reside en los sistemas de la propia compañía.
  • Platform as a Service (PaaS): En este categoría se permite que los clientes desarrollen sus propias aplicaciones y que se ejecuten en plataformas remotas. Por ejemplo, Google Ap Engine permite a los desarrolladores que programen aplicaciones para que puedan ejecutarse en sistemas proporcionados por el propio Google.
  • Infrastructure as a Service (IaaS): Esta última categoría es muy similar a la anterior, ya que el cliente desarrolla su propia aplicación, pero en este caso, el software se ejecuta sobre máquinas virtuales remotas, que es por lo que paga el cliente.
Estos modelos de computación presentan muchas ventajas en cuanto a ahorro de costes, pero también introducen nuevos riesgos en el funcionamiento cotidiano de las organizaciones, especialmente en lo que se refiere a la seguridad de la información.

Cada vez más código y datos residen en un conjunto más reducido de recursos hardware, que por lo tanto, se convierten en objetivos muy tentadores para posibles atacantes. De hecho, multitud de compañías y de agencias gubernamentaes han anunciado que no se plantean utilizar Cloud Compunting a corto plazo, a pesar de sus evidentes ventajas (sobre todo PaaS e IaaS), porque la utilización de este modelo implicaría incrementar enormemente sus riesgos corporativos. Ya hablaremos de la seguridad en este tipo de computación en futuras entradas.
aa
aa

Evento. Mesa de innovación PymeInnova.

Mañana, miércoles 7 de Octubre del 2009, se celebra en el hotel NH Las Rozas una nueva mesa de innovación organizada por el IMADE dentro del programa PymeInnova.

Será entre las 18.30 y las 20.30 y tratará acerca de la Gestión del Riesgo en la Empresa. En este caso yo misma seré la ponente, ya sabéis que es un tema que nos interesa especialmente en RedIndustria.

Espero que la información sea de vuestro interés. Un saludo a todos.
aaa

Gestión eficiente de recursos energéticos (I)

La gestión eficiente de los recursos energéticos inherentes a una organización se está convirtiendo en una práctica habitual dentro del entorno empresarial con el fin de alcanzar los objetivos operativos y estratégicos establecidos.

Durante varias entradas se analizará el alcance, metodologías, objetivos y herramientas disponibles en el mercado para llevar a cabo esta gestión.

El material utilizado para redactar estas entradas ha sido proporcionado por la Ingeniería Consultora Enco, quien ha incorporado una línea de negocio dirigida a aportar soluciones para la gestión energética (encoEnergy).

Para más información acerca de las actividades desarrolladas por Enco en este ámbito, se adjuntas los datos de contacto:

http://www.encoweb.com/

Manuel Guil

m.guil@encoweb.com


-------------------------------------------------------
La Gestión energética es el proceso de medir, controlar y optimizar los flujos energéticos (electricidad, gas, agua, vapor,…) en un edificio u organización , tanto en el sector privado como en el sector público. El ciclo asociado a la gestión energética se compone de cuatro fases:
m
1. Medir los consumos energéticos y recopilar datos de forma automática (conectándose a los contadores, circutores y demás dispositivos e intrumentos de medición).
2. Identificar ahorros, analizando los datos de consumo recogidos acerca de hábitos de consumo, gestión de equipos (p.e. iluminación) y factores constructivos (p.e. aislamiento).
3. Actuar, priorizando y ejecutando las acciones identificadas.
4. Retroalimentación, analizando los datos de consumo para determinar si las acciones realizadas han sido efectivas.
m
Se pueden distinguir dos tipos diferentes de objetivos vinculados a la gestión energética: globales y específicos.
m
Entre los globales destacan:
-El de reducir los daños causados al planeta por las sobreexplotación de recursos.
-El de mitigar la dependencia de combustibles fósiles que cada vez son mas limitados.

Entre los específicos se encuentra:
-El de reducir costes en un entorno creciente de precios.
-El de reducir emisiones de CO2 y consiguientes daños medioambientales que éstas causan, incrementando la sostenibilidad.
-El de reducir riesgos controlando, estabilizando y disminuyendo la demanda de energía es posible obtener mejores precios de suministro al estabilizar el consumo y hacerlo más predictible.
m
Estos proyectos están apoyados por diferentes instituciones europeas como:
-European Commission Energy - Energy Efficiency- http://ec.europa.eu/energy/efficiency/index_en.htm.
-2009 Intelligent Energy - Europe work programme.
m

USB 3.0 o SuperSpeed

USB es un interfaz serie que en su versión 1.1 permitía dos tasas de transferencia diferentes: 1.5 Mb/s para dispositivos lentos y 12 Mb/s para dispositivos que exigen mayor ancho de banda.

Una de las principales ventajas de este interfaz es que el computador identifica automáticamente el dispositivo que se conecta mientras opera (‘en caliente’) y lo configura sin tener que instalar drivers. Además, los periféricos de pequeño consumo reciben la alimentación por el bus y no necesitan enchufarse a la red eléctrica. Y cada puerto soporta la conexión de hasta 127 dispositivos, que pueden ser de muy diferentes características.

La versión 2.0 es totalmente compatible con USB 1.1, por lo que utiliza los mismos cables y conectores. En este caso se puede trabajar a tres velocidades, las dos de USB 1.1 y una más: 480 Mb/s. Este ancho de banda permitía la conexión de periféricos de nueva generación, como cámaras para vídeo-conferencias, impresoras y scaners de alto rendimiento y unidades de almacenamiento externo rápidas.

Pero después de ocho años trabajando con esta versión, se presetaron limitaciones en el ancho de banda y en la capacidad de alimentación. Por lo que se ha propuesto USB 3.0 y ya están en el mercado las primeras placas base que soportan est anueva especificación del interfaz.

En USB 2.0 el bus utilizaba un par de líneas para datos, una para corriente y una para toma de tierra. En USB 3.0 se añaden cinco líneas nuevas, dos de ellas se usarán para el envío de información y otras dos para la recepción, de forma que se permite el tráfico bidireccional (full-duplex), en ambos sentidos al mismo tiempo como ocurre con PCI-Express o Hipertransporte. El aumento del número de líneas permite incrementar la velocidad de transmisión desde los 480 megabits por segundo hasta los 4.8 gigabits por segundo.

Además en USB 3.0 se ha aumentado la capadidad de alimentación de 100 miliamperios a 900 miliamperios, con lo que podremos cargar más dispositivos o hacerlo más rápido.
sdss

System Platform 3.1. Programación orientada a Objetos y Modelo de información

Una de las principales características de System Platform es que la programación de la solución se realiza a través de plantillas de objetos que forman un Modelo de instalación o planta (en entornos industriales).

PROGRAMACIÓN ORIENTADA A OBJETOS:

El desarrollo Orientado a Objetos debe cumplir estos tres requisitos que definen lo que entendemos por Objeto:
,
-ENCAPSULAMIENTO: Podemos decir que un Objeto es un “Pequeño SCADA” que incorpora todos los Atributos que caracterizan a este tipo de aplicación.Un ejemplo: Físicamente, tenemos un Válvula. La representación lógica de esta Válvula será el Objeto=Plantilla $Válvula que llevará incorporado los atributos de Seguridad a nivel desarrollo y a nivel operación, Configuración Automática de Históricos, Scripting, Comunicaciones-I/O, Alarmas, Eventos y su Representación Gráfica.Toda la programación inherente a estos atributos está “encapsulada” en el objeto. Este objeto podrá ejecutarse en cualquier PC conectado a Red, sin necesidad de instalar ningún tipo de Software (solo unos componentes comunes basados en Arquitectura .Net) (Se está aplicando el concepto de WebServices de .Net – Software ejecutable en cualquier Hardware, pero traslado al entorno del Tiempo Real).
m
-POLIMORFISMO: Una vez que se han desarrollado una serie de Plantillas Genéricas (Padres) se pueden realizar otras Plantillas (Hijas) a partir de estas genéricas. Estas Hijas, tendrían unos atributos específicos, pero conservarían los atributos Básicos de las Plantillas Padre.
,
-HERENCIA: Los cambios en la plantilla se propagan automáticamente a todas las instancias. (O bien se propagan a las que se marquen como susceptibles de ser cambiadas).
,
La principal fortaleza del Desarrollo Orientado a objetos radica en que existe un trabajo importante de Desarrollo de Modelo y Desarrollo de Objetos Padre al principio del Proyecto. Sin embargo, una vez que se ha realizado este Proceso, la creación, puesta en marcha y mantenimiento de los Proyectos se realiza con gran facilidad.
m
De hecho, las empresas realizan Bibliotecas de Objetos que puedan extrapolarse a instalaciones similares. Junto a esta Bibliotecas, suelen aparecer lo que llamamos “Centros de Competencia”. Se trata de equipos de trabajo que se encargan de gestionar estos Objetos. Almacenamiento y Gestión del Conocimiento Tecnológico del modelo desarrollado, Pruebas de Ejecución de los objetos, Mejora y Control de Versiones, Elaboración de Documentación referente a utilización, etc…El objetivo principal de desarrollar proyectos aplicando esta tecnología es reducir los costes de desarrollo y mantenimiento de la aplicación. Las plantillas estándar disminuyen los costes de proyecto a proyecto.
,
DESARROLLO DEL MODELO DE PLANTA O INSTALACIÓN:
,
Otra de las ventajas de la Programación Orientada a Objetos, es que permite desarrollar un Modelo de Planta o Instalación. En definitiva un Modelo de Planta no es más que una representación lógica a través de Objetos, que a su vez pueden estar compuestos por otros subobjetos, de un entorno físico. Ejemplo: Un edificio de 5 Plantas, estará compuesto por un Área llamada Planta y esta Planta estará formado por los Objetos, Detector de Incendio, Detector de Presencia, Sistema de Seguridad. A su vez el Detector de Incendio, podrá estar formado por otros Subobjetos.
,
Además de tener un proyecto organizado que facilite el desarrollo del mismo, este modelo permite ordenar la información que el usuario requiera. En nuestro ejemplo: Histórico del Detector de Incendios de Planta 1.El modelo no solo ordena la información, sino que hace que el desarrollo de informes sea tan flexible como queramos. Los informes podrán cambiarse con simples cambios en el modelo.
,

Diferencias entre BPMN, BPML´s, BPML , WS BPEL y XPDL

-BPMN (Business Process Management Notation) es un estándar creado por la BPMI (Business Process Management Initiative) parala modelización de flujos de procesos de negocio y web services. BPMN como herramienta de notación de procesos define la formagráfica de construir un proceso, así como los diferentes objetos que se pueden utilizar para tal efecto.
m
-BPML´s (Business Process Modeling Languages). Los BPML son metalenguajes que permiten llevar a cabo el modelado deprocesos basándose en XML y realizar la integración con sistemas de información y de gestión utilizando web services, generalmente a través de WSDL (Web Service Description Language). Dentro de los BPML destacan el BPML (Business Process Modeling Language)desarrollado por la BPMI y el BPEL4WS o WS BPEL que en estos momentos es considerado como estándar de facto para la ejecución de procesos.
h
-WS BPEL (Web Services Business Process Language). Es un lenguaje de modelización de procesos basado en la utilización deservicios. Su desarrollo se realiza a través del (Web Service Definition Language), de manera que un proceso diseñado con WSBPEL puede ser expuesto a través de su propio WSDL y por tanto ser invocado como cualquier otro servicio web, facilitando la integración entre diferentes procesos. Es decir a través de WSBPEL un proceso puede invocar un servicio web para integrarse conun sistema de información o comunicarse con otro proceso.
n
WS BPEL nace como combinación de WSFL (Web Service Flow Language de IBM, orientado a grafos y basado en el control de los links entre tareas) y XLANG (Web Services for Business Process Design de Microsoft, basado en un control de flujos con secuencias,condiciones, bucles, etc).
m
-XPDL (XML Process Definition Language) es una representación basada en XML de un proceso, es decir es la forma de almacenar el proceso en formato físico (fichero) y se utiliza para que aplicaciones de diferentes fabricantes se entiendan entre ellas, principalmente utilizado como formato de intercambio entre los modeladores gráficos (herramientas BPA) y los motores de ejecución.
m

System Platform 3.1. Definición

En algunas de las entradas relacionadas con Wonderware, se ha referenciado System Platform como la solución propuesta por Wonderware para la visualización, control y gestión en tiempo real de entornos industriales e infraestructuras. A lo largo de varias entradas, vamos a hacer una descripción detallada de qué es System Platform, sus funcionalidades, arquitecturas posibles y sus capacidades de integración. En esta primera entrega, realizamos un descripción general de esta solución.
--------------------------------------------------------------------
,
System Platform es la Plataforma Tecnológica Estándar desarrollada por Wonderware para la Supervisión, Control y Gestión en tiempo real (SCADA) de entornos productivos e infraestructuras.
m
System Platform 3.1 se ha realizado basándose en la Arquitectura .Net de Microsoft. Esta característica hace que se convierta en un Middleware que facilita la integración con cualquier tipo de dispositivo de campo o con cualquier sistema de gestión corporativa de carácter transaccional.
.
Wonderware inicia el lanzamiento de esta nueva tecnología durante el año 2003 con la versión 1.0 atendiendo a las necesidades detectadas en el mercado que son entre otras la necesidad de supervisar y controlar entornos distribuidos, la de reducir los costes de desarrollo y mantenimiento de proyectos y la de integrar islas de automatización y ser capaces de interactuar con sistemas transaccionales.
,
System Platform 3.1 es la última versión desarrollada por Wonderware que mejora las versiones 1.0, 1.5, 2.0, 2.1 y 3.0 previamente comercializadas. System Platform está compuesto por un Entorno de Desarrollo (IDE, Integrated Development Environment), Mantenimiento (SMC, System Management Control) y Ejecución de Aplicaciones en tiempo real (AS, Application Server) que alberga Servicios Comunes tales como la gestión de históricos, reconocimiento de alarmas y eventos, gestión centralizada de la seguridad y acceso web a datos de proceso, sobre la que se construyen Módulos Funcionales que se van incorporando a medida que surgen necesidades para los usuarios de la aplicación (módulo de visualización y control de proceso, módulo de gestión de la información, módulo de mantenimiento, módulo de gestión de eficiencias productivas, módulo de gestión de la trazabilidad, módulo de alertas SMS, etc).
m
System Platform 3.1. realiza el desarrollo de aplicaciones utilizando la programación orientada a objetos en tiempo real. Los objetos son desarrollados y luego ejecutados en un entorno distribuido, de manera que las aplicaciones se abordan de forma integral, independientemente del número de señales que quieran ser controladas (hasta 1.000.000 de E/S) y de los puestos clientes que sean necesarios.
m
La tecnología proporcionada por Wonderware proporciona a clientes de distintos sectores la posibilidad de contar con un Partner Estratégico con una visión a largo plazo y con un mapa de ruta creíble.
,,

Organizaciones para el desarrollo de estándares para la gestión de procesos de negocio

Entre las organizaciones que desarrollan estándares para la gestión de procesos de negocio destacan BPMI.org (Business Process Management Initiative) que es un organización sin ánimo de lucro cuyo fin es potenciar el uso y desarrollo de soluciones de gestión de procesos dentro de las organizaciones. OASIS (Organization for the Advancement of Structured Information Standards), la OMG (Object Management Group) o W3C (World Wide Web Consortium) son organizaciones que se centra más en el desarrollo de estándares para seguridad, web, gestión de la cadena de suministro e interoperabilidad entre sistemas y aplicaciones.

La UN/CEFACT (United Nations/Centre for Trade Facilitation and Electronic Business) centra sus esfuerzos en incrementar la integración entre organizaciones a través del establecimiento de estándares para la gestión de transacciones, procesos y sistemas de información.

Por último cabe destacar la WfMC (Workflow Management Coalition) que como las anteriores no tiene ánimo de lucro y se centra en promocionar y desarrollar estándares para la interoperabilidad y conectividad entre soluciones para la gestión de flujos de trabajo (workflow).

De las organizaciones descritas son la BPMI.org y la UN/CEFAT quienes más tiempo han invertido en potenciar estándares que ayuden a la gestión de los procesos de negocio.

Dentro de la BPMI se crea el BPMN (Business Process Managament Nomenclature).
Actualmente el estándar más utilizado para la representación gráfica de procesos de negocio. Este estándar se complementa con el BPEL4WS (Business Process Execution Language for Web Services ), también denominado WS BPEL , como lenguaje de ejecución y modelado de procesos basado en XML e integrado con Web Services. En próximas entradas profundizaremos en los componentes principales de BPMN.
,,

Riesgos corporativos

Hablábamos antes del verano de la disciplina conocida como Enterprise Risk Management (ERM) que tanta importancia está cobrando en la actualidad.

Normalmente se pueden distinguir tres tipos de riesgo:
  • Los riesgos de un proyecto, que afectan principalmente a la planificación o a los recursos.
  • Los riesgos del producto, que afectan a la calidad o al rendimiento del resultado producido.
  • Los riesgos del negocio, que son aquellos que afectan a la organización y al cumplimiento de sus objetivos estratégicos.
Estos últimos son los que se denominan también riesgos corporativos, y deben ser el objeto de una buena estrategia ERM.

Cuando se plantea un Plan Integral de Gestión de riesgos Corporativos, hay que ir más allá de los riesgos que provocan pérdidas financieras (en los que suelen centrarse erróneamente muchos planes) y tener en cunta también aquellos que provocan un incumplimiento de plazos, de objetivos, de leyes (la LOPD, por ejemplo!) o incluso la desmotivación de los trabajadores o la degradación de la imagen corporativa en el mercado.

Para ello casi todos los planes estratégicos de gestión de riesgos se apoyan en una o varias herramientas tecnológicas. Las más habituales son las bases de datos de riesgos y/o documentales, las herramientas BPM (Bussiness Process Managament) y las herramientas ZLE (Zero Latency Enterprise). Aunque están surgiendo herramientas software dedicadas exclusivamente a la gestión de riesgos. Hablaremos de ellas en futuras entradas.
aa

Impacto de la Información en Tiempo Real suministrada por los Sistemas de Gestión Corporativos en las Relaciones Laborales (y V)

Teniendo en cuenta la clasificación de organizaciones descrita en la entrada Impacto de la Información en Tiempo Real suministrada por los Sistemas de Gestión Corporativos en las Relaciones Laborales (IV) , se pueden analizar los efectos que el tipo de estructura organizativa tendrá sobre el análisis acerca de las RRLL realizado anteriormente.
,
Comenzando por una empresa simple, la centralización de la toma de decisiones en una única persona que posee amplia información de su empresa y de su entorno, facilita enormemente la gestión de la información en tiempo real.
Por otro lado, esta tremenda centralización impide que la información fluya a los trabajadores. La poca participación de los trabajadores en la dirección del trabajo suele ser bastante desmotivadora para ellos en este tipo de empresa. Por lo tanto, la implantación de este tipo de sistemas, podría aprovecharse para implicar algo más a los trabajadores en la evolución del negocio, haciendo que tengan acceso en tiempo real a aquella información que pueda interesarles y mejorando enormemente las RRLL.
m
En el caso de una empresa con organización burocrática maquinal la normalización de procesos debería facilitar la implantación y la utilización de las herramientas de gestión en tiempo real a pesar de estar en un caso en el que las decisiones ya no se centralizan tanto como en el anterior.
Sin embargo, la dificultad para adaptarse a los cambios de este tipo de empresas, poco dinámicas por naturaleza, será una barrera importante.
m
Además en estas organizaciones suelen existir problemas de desmotivación y de absentismo laboral debido a los trabajos monótonos y rutinarios. Una herramienta de gestión en tiempo real ayudará a los empresarios a controlar mejor estas situaciones pero por ello, los trabajadores percibirán que sufren una nueva supervisión directa por culpa de la nueva herramienta.
m
Para una empresa divisional, la gestión de la información en tiempo real será siempre una iniciativa estratégica (de hecho son las primeras empresas que están abordando proyectos de implantación). Este tipo de empresa se caracteriza por tener una gran capacidad de reacción ante los riesgos. Presenta una mayor velocidad de reacción que otras organizaciones porque se tienen más cerca los problemas y se buscan más rápidamente soluciones. Así que este tipo de herramienta se verá rápidamente como una oportunidad de mejorar en esta línea.
Además, en este tipo de empresa cada división tiende a pensar que sus objetivos particulares son los más importantes, lo que suele repercutir negativamente en los resultados globales. Una herramienta de gestión de la información en tiempo real mejoraría la comunicación entre divisiones, mitigando este problema. Si se consigue que así lo perciban los trabajadores, la implantación de este tipo de herramientas no deberá ser muy complicada y favorecerá las RRLL.
n
Si nos centramos a continuación en las empresas con organización burocrática profesional, observamos que los profesionales suelen ser reacios a la coordinación con otros profesionales, ya que tradicionalmente, es una organización donde la autonomía del trabajador prima sobre otros aspectos.
Los profesionales son independientes, y no les gusta dar explicaciones a los demás. Existen situaciones en las que no se cumple con la responsabilidad, pero esto es muy difícil de controlar.
Así que, igual que en el caso de la organización burocrática maquinal, una herramienta de gestión en tiempo real sería tremendamente útil para el empresario, aunque probablemente, su implantación generará graves conflictos con los trabajadores.
m
Por último, en el caso de las empresas con organización innovadora, la flexibilidad adecuada para producir innovación conlleva el mismo tipo de problema. La ambigüedad estructural hace que sea normalmente sea más difícil identificar los problemas y quién es la persona encargada de resolverlos. Por lo que los trabajadores verán la herramienta de gestión en tiempo real como una amenaza que perjudicará su habitual independencia.
m
En resumen, en las organizaciones sencillas y divisionales, la implantación de sistemas de gestión de la información en tiempo real será más sencilla, ya que tanto los empresarios como los trabajadores verán este tipo de herramienta como una oportunidad de mejorar. Y por lo tanto las RRLL deberían mejorar tras el proyecto de implantación.
Sin embargo, en las organizaciones burocráticas y en las innovadoras, aunque los empresarios podrían obtener muchas ventajas con este tipo de solución, casi todas ellas están asociadas a una mayor supervisión y coordinación de las labores de los trabajadores. Esto hará que el personal perciba estas soluciones como una amenaza y será mucho más complicado conseguir una implantación y una utilización eficiente de estas herramientas. El conflicto en todos estos casos está prácticamente garantizado debido a la resistencia que los trabajadores opondrán a estas nuevas tecnologías. Y esto tendrá una repercusión negativa en las RRLL de la empresa si no se gestiona correctamente.
mm

CUDA

Ya hemos hablado en entradas anteriores de GPGPU (General Purpose GPU) o lo que es lo mismo, de la posibilidad de utilizar el procesador de las tarjetas gráficas (la GPU) para acelerar la ejecución de aplicaciones de propósito general que en principio nada tienen que ver con el tipo de programa para el que en principio está diseñada una GPU.

La GPGPU tradicional, basada en la utilización de APIs gráficas como Open GL o DirectX y los lenguajes de programación de shaders (el más conocido es Cg) sufría de las importantes limitaciones causadas por:
  • La utilización de los procesadores de fragmentos pero no de los de vértices desaprovechaba muchos recursos de la GPU.
  • La utilización de las texturas para almacenar los datos con los que se opera limita los tipos de datos, los modos de direccionamiento, obliga a “rellenar” en algunos casos, etc.
  • No existían operaciones para trabajar con números enteros o para operar a nivel de bit.

Con la aparición de las arquitecturas unificadas de NVidia (a partir de la serie 8 de GPUs), este fabricante propone la utilización de CUDA, Computer Unified Device Architecture, para intentar limitar estas superaciones.

¿Qué es CUDA?, del que tanto se escucha hablar últimamente. Simplificando, se trata de una arquitectura HW y SW que trata a la GPU (device) como un coprocesador de la CPU (host), que incorpora su propia memoria principal y que tiene la capacidad de ejecutar multitud de threads simultáneamente. Estos threads son diferentes de los que estamos habituados a manejar en la CPU, ya que son tremendamente ligeros y su creación, cambios de contexto y destrucción casi no consumen tiempo.

La idea es que los códigos se ejecuten en la CPU y cuando lleguen a partes en las que sea posible explotar el paralelismo de datos, se envíen los kernels de código de estas partes a la GPU para que pueda acelerar su ejecución. Esto hace posible mejorar increíblemente los tiempos de ejecución en multitud de aplicaciones de cómputo científico, simulación, procesado de imagen, etc, llegando incluso a conseguir cumplir restricciones de tiempo real antes inalcanzables.

CUDA posee su propio driver, lenguaje y entorno de programación. El driver permite la carga y puesta en ejecución de los programas, por lo tanto ya no es necesaria una API gráfica (aunque se pueden compartir datos con OpenGL y DirectX). Además proporciona una ayuda importante en la gestión de la jerarquía de memoria completa del sistema. Por ejemplo, optimizando la carga y descarga en background de datos hacia/desde la memoria de vídeo.

En cuanto al lenguaje y al entorno de programación, son muy similares a los empleados para programar en C, de hecho, se plantea como una serie de extensiones a este lenguaje, por lo que es mucho más sencillo aprender a programar la GPU que antiguamente. Eso sí, es necesario tener unos "rudimentos" de programación paralela para poder sacar partido de todos los recursos disponibles en la GPU.
aa