A favor del proceso distribuido

por | 10 octubre, 2019

Soy un acérrimo defensor del proceso distribuido. Sé que me reitero, pero en un momento en el que la tecnología ofrece micro-controladores avanzados por un precio menor que un conjunto de cables y un conector, esta parece la mejor solución.

Vuelvo a esta cuestión porque recientemente me han aparecido varias circunstancias que me reafirman en la idea.

  1. Un proyecto anterior en el que se solicitó el control de un interfaz de usuario separado ya que el resto estaba ya diseñado.
  2. Un proyecto en el que dividir el diseño en un micro-controlador de proceso de señales y otro de interfaz de usuario es una solución «óptima»
  3. Una sugerencia acerca de tecnología y arquitectura para montar un equipo con una interfaz de usuario avanzada (pantalla táctil grande y de alta velocidad, conexión en red…) pero que a su vez requiere un seguimiento de señales y control en tiempo real además de seguridad.
  4. Un sistema pre-existente en el que no se optó por esta solución y que claramente muestra los problemas de esta elección frente a la alternativa de un proceso distribuido.

En el primer caso, un procesador especializado se encarga de la gestión de 8 LED TRICOLOR con control de brillo además de un teclado capacitivo. ¿El acceso? Un simple bus I2C.

En el segundo caso, dos procesadores de 64 pines y 32 pines respectivamente hacen las funciones de uno de 100 pines. El precio suma de los dos seleccionados supera muy levemente el de la solución única. Pero, además, se sustituye un conector de 20 vías por uno de solo cuatro. Un cambio de última hora en el diseño afecta solamente a uno de los micro-controladores. El trabajo de desarrollo se separa en dos y se puede avanzar simultáneamente. Y la interfaz de usuario está lista para funcionar en otros equipos.

Para el tercer caso, se solicitaba ayuda para localizar una tarjeta de calidad industrial capaz de manejar gráficos con alta velocidad, pantalla táctil… Este es el típico problema en el que se suele emplear una Raspberry Pi. ¿En un entorno industrial? No estoy de acuerdo. Tras sugerir una tarjeta adecuada, se plantea la cuestión ¿Cuántas entradas/salidas tiene? ¿Y analógicas?¿Y PWM?. Esta es la situación en la que un sistema Linux deje de funcionar. La recomendación es usar una tarjeta externa con un micro-controlador capaz de mantener todas estas entradas/salidas al día e incluso efectuar tareas de control delicadas como actuaciones de seguridad sin intervención del sistema Linux. El Linux, para la interfaz de usuario y als comunicaciones de alta velocidad. Un micro-controlador de bajo costo para el resto.

El cuarto caso se refiere a una tarjeta que tiene un número elevado de entradas/salidas controladas desde una Raspberry-Pi mediante multiplexores y otros elementos similares. Al estar todo en la misma tarjeta y los elementos que controla alejados, los mazos de cables son complejos de instalar, añaden riesgo de ruidos al conjunto y complejidad a la tarjeta. Si esas señales se hubiesen dejado en manos de un controlador externo, el costo hubiese sido mucho menor, así como el riesgo de fallos por un conexionado delicado (menos conexiones, menos riesgo). El mantenimiento (se suelen requerir bastantes operaciones de mantenimiento) sería más simple e incluso lo sería el «modelo mental» del equipo. Lo que me pareció más triste de este caso es que el diseño se monta en una máquina que utiliza proceso distribuido. Ni tan siquiera así sirvió de inspiración. Ahora hay que montar un nuevo prototipo con unos pocos cambios (montaje manual) y un montón de componentes que se hubiesen evitado si se hubiese diseñado con proceso distribuido.

Una sola razón debiera ser suficiente: Menos cables, más orden. Pero hay todo un conjunto de razones: desde facilitar el desarrollo en equipo y las pruebas separadas de cada elemento hasta la reducción de costos y el aumento de fiabilidad. Voy a incidir en este punto: Si hay un elemento separado manejando un interfaz de usuario y falla por un error de diseño u otra causa, el resto del equipo puede funcionar correctamente o incluso avisar de la incidencia. Si el código está en el mismo micro-controlador que ejecuta otras funciones, el funcionamiento de todo el conjunto se verá comprometido. Y en esta situación será más difícil encontrar el origen del fallo.

En este tipo de decisiones, influye mucho desde experiencia de cada ingeniero, el miedo a afrontar «riesgos» sobre aspectos que no se manejan habitualmente y hasta el ego que pretende controlar cada detalle y evitar que caiga en manos de terceros. Buscar razones (y excusas) propias en el próximo diseño para seleccionar un proceso distribuido será un buen ejercicio para tomar la decisión adecuada (sobre todo porque ya sabemos de antemano cuál es).

Deja una respuesta