\documentclass[a4paper,10pt]{article}
\usepackage[latin1]{inputenc} %linux
\usepackage[spanish, activeacute]{babel}
\usepackage{fancyhdr}
\usepackage{listings}
\usepackage[usenames]{color}

\pagestyle{fancy}
%\pdfpagewidth 5.5in
%\pdfpageheight 11in

%\pagestyle{fancy}
%\headheight 35pt

%\rhead{Right top}
%\chead{Middle top}
%\lhead{Left top}
%\rfoot{Right bottom}

%\cfoot{\thepage}
%\lfoot{Left bottom}

%\usepackage[latin1]{inputenc} %windows

%\usepackage[dvips]{epsfig}
%\usepackage{mathrsfs}
%\usepackage{amsmath}
%\usepackage{pst-all}
%\usepackage{amssymb}
%\usepackage{fullpage}
\usepackage{graphicx}

\begin{document}

\fancyhf{}
\fancyhead[L]{\leftmark}
\fancyhead[R]{RMES} %nombre de capítulo
\fancyfoot[C]{
    Centro de Desarrollo de Gestión Empresarial.\\
    1 Oriente 1097 - Viña del Mar, Chile.\\
    Fono:(56) (32)688987 - Fax:(56) (32)2684079
    }
\fancyfoot[R]{\thepage} % la pagina

\renewcommand{\footrulewidth}{0.4pt}

\lstset{
language=Java,
morekeywords={public,void,new},
keywordstyle=\color{blue},
basicstyle=\footnotesize,
numbers=left,
numberstyle=\tiny
}

\title{\textbf{
Proceso de Propagación Histórica bajo Demanda\\
Software RMES\\
}}
\author{
    Centro de Desarrollo de Gestión Empresarial.\\
    1 Oriente 1097 - Viña del Mar, Chile.\\
    Fono:(56) (32)688987 - Fax:(56) (32)2684079\\
    empresa@mes.cl
    }
\date{Junio, 2010}

\maketitle

\abstract{El presente informe explicará el proceso de propagación de detenciones históricas para el software RMES. Se detallarán los puntos que hasta el momento el autor comprende a cabalidad. Secciones que no sean exhaustivamente explicadas serán completadas en el futuro cuando se tenga compresión completa de todo el proceso. Este documento esta dirigido particularmente a los actuales y futuros desarrolladores del software RMES, por lo que se utilizará en gran parte de éste la jerga técnica informática asociado al software.}

\newpage

\tableofcontents

\newpage
\section{Introducción}
Uno de los procesos más importantes del software RMES es realizar la propagación de detenciones desde las raíces del árbol de jerarquía de sistemas, que representan a los equipos, hasta lo más alto de éste, que en visión sistémica representa a toda la planta en estudio. La importancia de este proceso radica en que los indicadores que se puedan obtener luego de la propagación son estimadores de gran precisión y muy representativos de la realidad, a diferencia de los estimadores probabilisticos obtenidos mediante estimación de parámetros que son muy inexactos para explicar el comportamiento de algún componente de la planta y que además no pueden ser ajustados a un rango de tiempo arbitrario.

Este proceso puede ser en línea (on line) o bajo demanda (on demand). El primero concepto se asocia a realizar el proceso cada vez que exista algún cambio que afecte al cálculo en algún punto de la planta; el segundo concepto se entiende como realizar el proceso completo sólo cuando se estime conveniente.

Este documento está enfocado a una propagación bajo demanda, es decir, realizar el proceso sólo cuando se requiera, específicamente, antes de querer obtener algún indicador de mantenibilidad histórica.

La idea en sí no es compleja, pero se necesita comprender mínimamente como se trajaban las detenciones en una planta. En general, todos los equipos en una planta presentan defectos en su funcionamiento, los cuales dentro del software son registrados como tuplas (falla o detención). Por ahora, sólo es necesario saber que una tupla como mínimo tiene una fecha de inicio y una duración. La representación gráfica de un conjunto de fallas se realiza mediante un cronograma de tiempo (en alguna ''métrica de tiempo'' como ''horas''). Cada falla se representa con un bloque ubicado sobre el intervalo de tiempo asociado a la tupla, en donde la altura del bloque sólo es útil para hacer notar la existencia del intervalo dentro de la unidimensionalidad de este tipo de gráficos.

La visión sistémica de un planta permite ver cada componente como un compuesto, valga la redundancia, de algo ''más grande'', siendo este último objeto ''más grande'' también es un compuesto de algo superior. El ejemplo más simple es un planta con maquinarias en serie, un conjunto de máquinas alineadas, en donde la máquina siguiente en el proceso se nutre de lo entregado por la anterior. En este sencillo ejemplo se puede ver claramente que existe un gran padre que es ''la planta'' y un subconjunto de ''hijos'' que son las maquinarias. Sabemos que la planta completa se detendrá cuando cualquiera de los hijos falle. La figura \ref{fig:00} representa un escenario simulado de la planta en donde, las máquinas fallas en distintos momentos. Estas fallas se ven reflejadas directamente en la planta, debido a su configuración en serie.

\begin{figure}[htp]
\centering
\includegraphics[scale=0.20]{img/crono00.eps}
\caption{Detenciones de las maquinarias que suben hacia la planta en serie.}
\label{fig:00}
\end{figure}

Por ejemplo, si la planta de alguna manera tuviese sus máquinas organizadas en paralelo, el resultado sería distinto, dado que por definición la planta completa fallará sólo cuando todas las máquinas estén detenidas al mismo tiempo. La figura \ref{fig:01} ilustra esta situación.

\begin{figure}[htp]
\centering
\includegraphics[scale=0.2]{img/crono01.eps}
\caption{Detenciones de las maquinarias que suben hacia la planta en paralelo.}
\label{fig:01}
\end{figure}

Como se puede observar, la llegada de detenciones a la planta depende de la configuración de la planta, por ende, depende de criterios especiales para cada caso. 


\section{Implementación}
\subsection{Diagrama de Clases}
Las clases que la figura \ref{fig:02} muestra se encuentran ubicadas en el paquete \textit{cl.cgeconsultores.mes.main.historicCalculations} y representan la implentación realizada para la propagación bajo demanda en el software RMES.

\begin{figure}[htp]
\centering
\includegraphics[scale=0.24]{img/diagrama.eps}
\caption{Diagrama de clases.}
\label{fig:02}
\end{figure}


\subsection{Llamada a la propagación}
El proceso comienza cuando, en algún momento, se necesita realizar algún cálculo de mantenibilidad sobre uno o varios subsistemas, generalmente, sobre toda la planta. La interfaz \textit{IHistoricManager} encapsula la llamada a la propagación con el método 
\begin{lstlisting}[language=Java, numbers=left, numberstyle=\tiny]
public void propagateHistoricCalculations(Subsystem,Date,Date)
\end{lstlisting}

Dado que se trata de una interfaz, el método es sobreescrito en cada clase que la implemente. Este es el caso de la clase \textit{DefaultHistoricManager}, la cual particularmente se encarga de hacer la propagación bajo demanda. En ella se puede encontrar un código muy simple:

\begin{lstlisting}[language=Java, numbers=left, numberstyle=\tiny]
public void propagateHistoricCalculations(
  Subsystem rootVisit, Date from, Date to){
  rootVisit.accept(new HistoricAvailabilityVisitor(from, to));
}
\end{lstlisting}

En la esquina superior izquierda de la figura \ref{fig:02} se representa esta relación. El objeto \textit{rootVisit} es un \textit{Subsystem} que generalmente es la planta completa (el subsistema contenido por la clase \textit{Chain}). Como se puede observar, la propagación utiliza el paradigma de visitas (Patrón Visitor) y es posible utilizar cualquier nodo del árbol de subsistemas como raíz de la visita. Esta visita en particular se realiza \textrm{desde las hojas del árbol hacia arriba}, idea que se debe tener siempre presente a lo largo de este documento.

\subsection{Falla y Bloque de Falla}
Una Falla, representada por la interfaz \textit{IFailure}, inicialmente es en sí una redución de una tupla, representada por la clase \textit{ImpactImportedTuple}, que almacena información de una detención y su fin es el de agilizar el proceso de propagación, dado que es un objeto más liviano. Esto es ocurre al principio de la propagación, la transformación de tuplas a fallas, es decir, por cada detención ingresada a un subsistema (que sea abordado por la propagación), tendrá su contraparte como falla, más específicamente, como Falla Unitaria, representada por la interfaz \textit{IFailureUnit}. Mientras avance la propagación, se crearán nuevas fallas que en resumidas cuentas, son subfallas (cortes de las fallas originales) o uniones de varias fallas (conocidas como Fallas Compuestas, representadas por la interfaz \textit{ICompositeFailure}).

Un Bloque de Falla, representado por la interfaz \textit{IFailureBlock}, es un objeto contenedor que contiene Fallas que se encuentren traslapadas. Esto quiere decir que dentro de un Bloque de Fallas cada falla al menos intersecta con al menos una existente dentro del bloque, arbitrariamente, lo denominaremos un conjunto cerrado. Cada Bloque de Falla es independiente uno de otro, en el sentido de que no comparten ''espacio de tiempo'', por definición, no existen traslapes entre bloques.

\newpage
\section{Los procesos}
\subsection{Vista General}
Dado el uso del patrón Visitor para la implementación de la propagación bajo demanda, se realiza una visita en profundidad recorriendo desde las hojas hacia arriba hasta abarcar todos los nodos del árbol de subsistemas de la planta. En todo punto de la visita, en cada nodo o subsistema, se pueden enumerar los siguientes pasos que se realizan:
\begin{enumerate}
    \item Procesamiento de Datos Importados: Crear bloques de fallas de los datos importados del subsistema: se realiza a todo nivel, siempre y cuando el nodo visitado contenga tuplas.
    \item Procesamiento de Bloques Inferiores: Cruzar los bloques del subsistema actual con los bloques de los hijos: sólo se puede realizar para nodos que no sean hojas, o sea, no se aplica para \textit{Equipment}'s.
    \item Procesamiento Global de Bloques: consta de 4 subprocesos:
    \begin{enumerate}
       \item Cortado (\textit{BlockSplitterRefactor}): proceso de guillotinado de fallas.
       \item Chequeo de Sobrecapacidad (\textit{OvercapacityProcesorRefactor}): chequeo de impactos para subsistemas en fraccionamiento o redundancia.
       \item Jerarquizado (\textit{HierarchySelectorRefactor}): implementación de reglas de jerarquía que rige el comportamiento de las fallas que ''subirán'' al subsistema padre.
       \item Juntado (\textit{JoinerRefactor}): Unión de fallas contiguas con propiedades similares.
    \end{enumerate}

    \item Procesamiento Final: Crear la base histórica y asignarla al subsistema.
\end{enumerate}


\subsection{La clase \textit{SimpleHistoricAvailability}}
Como se puede observar en el diagrama de la figura \ref{fig:02}, la clase \textit{HistoricAvailabilityVisitor} implementa la interfaz \textit{SubsystemVisitorI}, lo cual nos dice que esta clase es un visitador de subsistemas. El código de esta clase es simple:

\begin{lstlisting}[language=Java, numbers=left, numberstyle=\tiny]
public class HistoricAvailabilityVisitor implements SubsystemVisitorI {
  private IPropagator propagator;

  public HistoricAvailabilityVisitor(Date from, Date to) {
    SimpleInterval interval = new SimpleInterval(from, to);
    BlockProcessorI bt = new BlockTransformerRefactor();
    this.propagator = new SimpleHistoricAvailability(interval, bt);
  }

  @Override
  public void visit(Subsystem ss) {
    this.propagator.calculateHistoricBase(ss);
  }
}
\end{lstlisting}

La interfaz \textit{IPropagator} simplemente fue creada con el fin de que en algún futuro se pueda implementar hebras al procesamiento de bloques. Por ahora, su única instancia conocida es la clase \textit{SimpleHistoricAvailability}, a la que abordaremos nuestra atención.

Esta clase se encarga de coordinar todos los procesos principales descritos en la sección anterior. El código para el método \textit{calculateHistoricBase(Subsystem)} es el siguiente:

\begin{lstlisting}
  @Override
  public void calculateHistoricBase(Subsystem ss) {
    this.blocks.clear();
    this.ss = ss;

    this.importedProcessor.processImportedData(ss, blocks, rangeOfAnalysis);
    this.failureProcessor.processFailureData(ss, blocks, rangeOfAnalysis);
    processBlocks();
    createBase();
  }
\end{lstlisting}

Se pueden ver claramente los 4 procesos principales: uno para los datos importados, otro para para juntar las fallas del subsistema actual con la de los hijos, otro referente al proceso completo de todos los bloques del subsistema y finalmente uno para la creación y asignación de la base histórica.

\subsection{Procesamiento de Datos Importados}
Es realizado por la clase \textit{ImportedDataProcessor}. Primero, justa los datos importados del subsistema al rango de fechas en estudio, filtrando aquellas tuplas que estan fuera de rango y cortando aquellas que se ubican en los bordes. Sólo se consideran las tuplas que detienen al sistema. De las tuplas que seleccionadas, se transforman a fallas y se crean los primeros bloques. Cada bloque es independiente y contiene fallas traslapadas. Como corolario, si no existen traslapes en las fallas, se crearán tantos bloques como fallas existan. Un bloque de falla contiene al menos una falla.

\subsection{Procesamiento de Bloques Inferiores}
Es realizado por la clase \textit{FailureDataProcessor}. Une la lista de bloques creados en el paso anterior con la lista de bloques de cada hijo. Básicamente, cada falla de cada hijo produce la unión de varios bloques de falla si éste es contenido por todos ellos.

\subsection{Procesamiento Global de Bloques}
Es realizado por la clase \textit{BlockTransformerRefactor}. Consta de 4 subprocesos. Dentro de la clase \textit{SimpleHistoricAvailability} en el método \textit{processBlocks()} se puede encontrar el código que gatilla el procesamiento:

\begin{lstlisting}
  private void processBlocks() {
    for (FailureBlock fb : blocks) {
      fb.setSubsystem(ss);
      blockTransformer.process(fb);
    }
  }
\end{lstlisting}

Dentro de la clase \textit{BlockTransformerRefactor} en el método \textit{process(FailureBlock)} se encuentran las llamadas a los subprocesos:

\begin{lstlisting}
  @Override
  public void process(FailureBlock block) {
    Subsystem ss = block.getSubsystem();
    if (ss instanceof Equipment) {
      Equipment equipment = (Equipment) ss;
      if (equipment.getTreatAsSubsystem()) {
        return;
      }
    }

    block.sortFailures();
    splitter.process(block);
    if (ss instanceof FractionMachine &&
       ((FractionMachine) ss).getSubsystemImpactSum() > 1.0) {
      overcapacity.process(block);
    } else if (ss instanceof RedundantMachine) {
      overcapacity.process(block);
    }
    selector.process(block);
    if (!(ss instanceof FractionMachine)) {
      joiner.process(block);
    }
  }
\end{lstlisting}

\subsubsection{Cortado}
Es realizado por la clase \textit{BlockSplitterRefactor}.

\subsubsection{Chequeo de Sobrecapacidad}
Es realizado por la clase \textit{OvercapacityProcesorRefactor}.

\subsubsection{Jerarquizado}
Es realizado por la clase \textit{HierarchySelectorRefactor}.

\subsubsection{Juntado}
Es realizado por la clase \textit{JoinerRefactor}.

\subsection{Procesamiento Final}
Crear la base histórica y asignarla al subsistema.

\begin{lstlisting}
  private void createBase() {
    NewHistoricBase hb = new NewHistoricBase();
    for (FailureBlock fb : blocks) {
      hb.addFailureBlock(fb);
    }
    ss.setNewHistoricBase(hb);
  }
\end{lstlisting}

\end{document} 
