Mostrando entradas con la etiqueta Modelo-CIM. Mostrar todas las entradas
Mostrando entradas con la etiqueta Modelo-CIM. Mostrar todas las entradas

miércoles, agosto 14, 2013

Los niveles de capacidad de CMMI


Un nivel de capacidad consiste en una meta genérica y sus prácticas genéricas relacionadas en la medida que se relacionan con un área de proceso, las cuales pueden mejorar los procesos de la organización asociados con esa área de proceso. En la medida que se satisface la meta genérica y sus prácticas genéricas en cada nivel de capacidad, se obtienen los beneficios de mejora de procesos para esa área de proceso.
Los seis niveles de capacidad, especificados por los números 0 hasta 5, son los siguientes:
0. Incompleto
1. Realizado
2. Gestionado
3. Definido
4. Gestionado cuantitativamente
5. En optimización
El hecho de que los niveles de capacidad 2 a 5 utilicen los mismos términos que las metas genéricas 2 a 5 es intencionado, por que cada una de estas metas genéricas y prácticas genéricas reflejan el significado de los niveles de capacidad en términos de metas y práctica que se pueden implementar. Los niveles de capacidad son los siguientes:

Nivel de capacidad 0: Incompleto

Un "proceso incompleto" es un proceso que, o bien no se ejecuta, o se ejecuta parcialmente. Al menos una de las metas específicas del área del proceso no se satisface y no existe metas genéricas para ese nivel, ya que no hay ninguna razón para institucionalizar un proceso ejecutado parcialmente.

Nivel de capacidad 1: Realizado

Un proceso de nivel de capacidad 1 se caracteriza como un "proceso realizado". Un proceso realizado es un proceso que satisface las metas específicas del área de proceso. Soporta y permite el trabajo necesario para producir los productos del trabajo.
Aunque el nivel de capacidad 1 da como resultado mejoras importantes, esas mejoras pueden perderse en el tiempo si no se institucionalizan. La aplicación de la institucionalización (las prácticas genéricas de CMMI en los niveles de capacidad 2 a 5) ayudan a asegurar que las mejoras se mantendrán.

Nivel de capacidad 2: Gestionado

Un proceso de nivel de capacidad 2 se caracteriza como un "proceso gestionado". Un proceso gestionado es un proceso realizado (nivel de capacidad 1) que tiene la infraestructura básica dispuesta para soportar el proceso. Se planifica y ejecuta de acuerdo a políticas; emplea personal con habilidades; tiene los recursos adecuados para producir resultados controlados; involucra a las partes interesadas relevantes; se monitoriza, controla y revisa; y se evalúa la adherencia a su descripción del proceso. La disciplina de proceso reflejada por el nivel de capacidad 2 ayuda a asegurar que las prácticas existentes se mantienen durante tiempo de estrés.

Nivel de capacidad 3: Definido

Un proceso de nivel de capacidad 3 se caracteriza como un "proceso definido". Un proceso definido es un proceso gestionado (nivel de capacidad 2) que se adapta a partir de un conjunto de procesos estándar de la organización, de acuerdo a las guías de adaptación de la organización, y contribuye a los activos de proceso d ela organización con productos del trabajo, medidas e información adicional de mejora de procesos.
Una distinción crítica entre los niveles de capacidad 2 y 3 es el alcance de los estándares, descripciones de proceso y procedimientos. En el nivel de capacidad 2, los estándares, descripciones de proceso y procedimientos pueden ser bastante diferentes en cada instancia específica del proceso. En el nivel de capacidad 3, los estándares, descripciones de proceso y procedimientos para un proyecto se adaptan a partir del conjunto de procesos estándar de la organización, para ajustarse a un proyecto o unidad organizativa particular, y son, por tanto, más consistentes, excepto para las diferencias permitidas por las guías de adaptación.
Otra distinción crítica es que en el nivel de capacidad 3, los procesos se describen normalmente de forma más rigurosa que en el nivel de capacidad 2. Un proceso definido establece claramente el propósito, las entradas, criterios de entrada, actividades, roles, medidas, etapas de verificación, salidas y criterios de salida. En el nivel de capacidad 3, los procesos se gestionan de forma más proactiva utilizando una comprensión de las interralaciones de las actividades dle proceso y de las medidas detalladas del proceso, de sus productos del trabajo y de sus servicios.

Nivel de capacidad 4: Gestionado cuantitativamente

Un proceso de nivel de capacidad 4 se caracteriza como un "proceso gestionado cuantitativamente". Un proceso gestionado cuantitativamente es un proceso definido (nivel de capacidad 3) que se controla utilizando técnicas estadísticas y otras técnicas cuantitativas. Se establecen los objetivos cuantitativos de calidad y de ejecución del proceso, y se utilizan como criterios para gestionar el proceso. Se comprende la calidad y el rendimiento del proceso en términos estadísticos y se gestionan a lo largo de la vida del proceso.

Nivel de capacidad 5: En optimización

Un proceso de nivel de capacidad 5 se caracteriza como un "proceso en optimización". Un proceso en optimización es un proceso gestionado cuantitativamente (nivel de capacidad 4) que se mejora en base a una comprensión de las causas comunes de variación inherentes al proceso. El enfoque de un proceso en optimización es mejorar continuamente el rango de la ejecución del proceso mediante mejoras, tanto incrementales como innovadoras.

Tomado de: Articulo Original

viernes, mayo 06, 2011

STD OPC

Tomado de:ESTANDARD OPC

31 diciembre 2009


Estándares OPC

Las aplicaciones informáticas que encontramos en los sistemas de control, cuentan con un módulo de adquisición de datos procedentes de los dispositivos programables (plc, dcs, rtu…) de la instalación. Con el objetivo de evitar que cada aplicación deba implementar drivers de comunicación para todos los protocolos que puedan necesitarse y desarrollar un estándar común, surgió en Mayo de 1995 la OPC Foundation. En cooperación con Microsoft, el núcleo inicial lo formaron las empresas: Fisher-Rosemount, Rockwell Software, Opto-22, Intellution e Intuitive Technology.

Las especificaciones se basaron en las tecnologías de Microsoft COM (Component Object Model) y DCOM (Distributed Component Object Model). De esta manera, si se instalan los servidores OPC necesarios, los desarrolladores de software industrial sólo necesitan implementar un cliente OPC para sus comunicaciones (la realidad es que se han seguido manteniendo todos los drivers específicos y se ha añadido el driver para OPC).


Actualmente OPC es un conjunto de estándares:

  • OPC Data Access: el primero en aparecer, para la comunicación en tiempo-real con controladores programables. De los controladores programables se ha pasado a desarrollar servidores para cualquier aplicación, cómo las bases de datos o los ERP’s (aunque se aprovecha el hecho de que algunos SCADAs tienen malas interfaces con bases de datos, pero que podemos solventar creándonos dll’s muy sencillas y eficientes)
  • OPC Alarms&Events: en el Data Access, se establece un flujo continuo de datos entre el servidor y los clientes, pero hay muchas señales con poca variabilidad que dan lugar a un tráfico innecesario. Para mejorar la eficiencia, este estándar define la comunicación de las notificaciones/mensajes que el servidor envía a los clientes (suscriptores).
  • OPC Historical Data Access: frente a las peticiones en tiempo-real, se añade la capacidad de incluir en la petición la fecha/hora. Esto implica que los servidores OPC deben almacenar (y gestionar) los datos leídos. Pretende eliminar el papel de los Historizadores, pero parece difícil que pueda competir con ellos y sus drivers para el acceso por http o SQL.
  • OPC Batch: basado en el estándar de Batch ISA88, el servidor OPC deberá mantener listas de los Batchs ejecutados y calcular datos sobre los mismos. No existen apenas servidores OPC Batch. Sólo Yokogawa y algunas pequeñas empresas los tienen, porque los softwares de gestión de Batch ya realizan todas las funciones a partir de los datos de tiempo real.
  • OPC Data eXchange: comunicación entre servidores, útil para implementar redundancia y balanceo de comunicaciones.
  • OPC XML-DA: reglas y formatos para el intercambio de datos en formato XML.
  • OPC Complex Data: estandariza estructuras complejas, como ficheros xml o estructuras binarias.
  • OPC Commands: en fase de desarrollo, el objetivo es poder ejecutar comandos (identificación, monitorización, ejecución de órdenes) en los equipos finales.
  • OPC Unified Architecture: es un conjunto de especificaciones no basadas en Microsoft COM, para el desarrollo de servidores en cualquier plataforma.
  • OPC Security: surge para incrementar la seguridad de las comunicaciones, dado que la seguridad que proporcionan los sistemas operativos no es suficiente. En la práctica es poco utilizado, porque la adopción del estándar implica un rediseño del software que los desarrolladores no han realizado. Se espera que se incluya dentro de los productos basados en OPC Unified Architecture.
  • OPC Express Interface: es una especificación para el desarrollo de clientes en .Net, intentando unificar y regular los desarrollos que cada fabricante estaba desarrollando.

Diego López
S21Sec Labs