Tal vez muchos de ustedes, lectores, no conozcan lo que es eso, o piensen que sólo se trata de robots. Para los que sí saben, enhorabuena, mas les contaré algo que tal vez no conozcan.
Al ritmo en el que los nuevos dispositivos mecatrónicos van encontrando un lugar en las industrias y en los productos que consumimos en la actualidad, se vuelve cada vez más importante la velocidad de desarrollo del producto, y por supuesto, el conocimiento y la práctica de metodologías de diseño que permitan ahorrar tiempo y esfuerzo del desarrollador. Ya no se trata de reinventar la rueda cada vez que se diseña algo, sino el realizar el mejor diseño inicial posible y continuar construyendo sobre lo antes hecho.
Esto quiere decir que nuestros primeros diseños, a pesar de ser (quizás) hechos sin experiencia previa, deben ser cada vez más flexibles, fácilmente mantenibles y escalables. Asimismo, la participación de los sistemas de información en procesos y productos mecatrónicos es cada vez mayor, por lo que las metodologías que se aplican en esa área también deben comenzarse a implementar en la mecatrónica. Así que, partiendo un poco de mi experiencia en el desarrollo de software, trataré de analizar el diseño y construcción de un dispositivo mecatrónico de acuerdo a principios de diseño que faciliten eso.
Primeramente, comenzaremos definiendo los conceptos de diseño de software y sus analogías en el contexto mecatrónico.
Inicialmente se tiene la capa de infraestructura en software. Esta usualmente se refiere a la última capa del sistema en la que se lleva a cabo operaciones de persistencia de datos, es decir, se guarda y obtiene la información contenida en las variables del sistema, ya sea en un sistema de archivos o en una base de datos. Esto podríamos verlo en un dispositivo mecatrónico como la última capa posible de nuestro sistema, los que nos permitirían guardar y obtener información acerca de nuestro dispositivo. En otras palabras, serían los sensores y actuadores de nuestro dispositivo. Viéndolo así, un sensor nos permitiría obtener información mientras que el actuador permitiría "guardar" una variable de nuestro sistema.
A continuación, se encuentra una capa a veces llamada dominio y otras veces llamada lógica de negocios. Es en esta capa donde se encuentran las clases dedicadas a hacer que se haga algo en el sistema. En otras palabras, si hablamos de un sistema de administración de empleados, en esta capa se deben implementar las cuestiones que permiten administrar empleados, cuestiones que si bien están ligadas con la capa de infraestructura, no dependen de ésta. Por ejemplo, no nos importaría cómo están guardados los datos, sino el saber que si debemos trabajar con ellos, estarán estos disponibles de cierta manera (e.g. como objetos o instancias de una clase Empleado). En un dispositivo mecatrónico encontramos un gran parecido, por ejemplo: ¿qué tal si, ante una petición expresa de un cliente se requiere instalar un sensor distinto al de todos los demás productos del mismo modelo? Sería necesario reprogramar todo para asegurarse de que funcione. En cambio, si se diseña la programación del producto o proceso de tal manera que sólo sea necesario modificar la información concreta del sensor, sin modificar lo que otras capas más abstractas esperan de él, el mantenimiento y/o desarrollo de nuevas versiones del producto se vuelve increíblemente sencilla.
Siguiendo, podemos definir una capa llamada de aplicación. Es en esta capa donde se introduce el concepto de API (Application Programming Interface), concepto fácilmente resumible: es una serie de librerías que implementan funciones útiles para el desarrollo de sistemas basados en ella. Un ejemplo son las Collections de Java. Éstas son una serie de estructuras (muy) útiles para el desarrollo de sistemas, como listas ligadas, pilas, colas, entre otros. Esto le permite al desarrollador pasar menos tiempo implementando estructuras de datos necesarias para su programa y más tiempo pensando en el correcto modelado, diseño y lógica de su aplicación. La idea detrás de estas API es ofrecer una interfaz fácil de usar para obtener acceso a los datos del sistema, con el objetivo secundario de permitir a terceros construir sus aplicaciones con los datos de tu sistema embebidos (como el API de Facebook, que te permite crear tus "aplicaciones" en Facebook mismo, utilizando los datos que Facebook tenga sobre tus usuarios), o crear aplicaciones para tu sistema, como versiones para móviles de redes sociales, como Twitter. En un sistema mecatrónico, la capa de aplicación es una capa invisible: existe sólo como software, usualmente en el controlador del sistema (que no sólo funciona como intermediario, usualmente tiene también las funciones propias de un controlador, con su propia ley de control). Al final de esta entrada me ocuparé de un ejemplo concreto y bien conocido de la mecatrónica y se disectará a fin de encontrar las diversas capas de las que les hablo.
Finalmente, se encuentra la capa más conocida (debido a que es la capa visible después de todo el proceso), la interfaz de usuario. La función de esta capa es fácilmente intuida: trata sobre la manera de presentar la información del sistema al usuario y en ocasiones permitir que éste interfiera en el funcionamiento del sistema. En otras, la interfaz es la única manera de que el sistema funcione, es decir, sin interfaz el sistema no está completo, es inútil. En la mecatrónica, nos encontramos con una flexibilidad inmensa al implementar una interfaz. Como ejemplos, fácilmente podemos pensar en LED's indicadores, displays de 7 segmentos, LCD's, pantallas sensibles al tacto, luces, sonidos, movimientos, entre otros. Todos los anteriores muestran información sobre el proceso o producto al usuario, pero no permiten modificar la operación de éste. Sin embargo, con interfaces como joysticks, botones, switches, controles (como los de Wii), interfaces basadas en la comunicación con otros dispositivos como celulares, tablets y computadores, entre otras, usualmente nos es posible modificar el comportamiento de nuestro dispositivo o proceso mecatrónico. Esta capa entonces no se preocupará de qué sensores, actuadores, microcontrolador o elementos en general contenga nuestra creación, sino que sólo será el puente entre el usuario y el API.
Entonces, ya sabemos cómo podemos dividir nuestro producto o software y en qué capas usualmente conviene hacerlo. Ahora veámoslo concretamente en el siguiente caso: un robot móvil.
Al tener un robot móvil nos encontramos con diversas cuestiones: peso, volumen, instrumentación, procesamiento, entre otras. Así que apliquemos el enfoque de capas al proceso de diseño.
Si lo que buscamos es un software con las características previamente mencionadas (flexibilidad, facilidad de manutención, facilidad para añadir nuevas funciones, etc) para el robot, entonces debemos pensarlo como una serie de capas que se comunicarán entre sí.
- Primero: capa de infraestructura. Requeriremos crear métodos o funciones que nos permitan mover nuestros motores. No importará qué motor usemos al final del proceso si éstas funciones son bien diseñadas. Una función así sería aquella que, con sólo requerir una velocidad de entrada, fuera capaz de calcular la frecuencia del pulso necesario para lograrla, teniendo en cuenta dentro de la misma función el tipo de motor que se eligió, y las limitantes de éste. Lo mismo sucede con los sensores, si al inicio se decide utiliza un sensor analógico cuya salida se encuentre entre los 0 y 5 V, si después lo cambiamos por uno cuya salida sea distinta, sólo será necesario modificar la función que trate con él. Un ejemplo, al utilizar un sensor de temperatura analógico tendremos una salida entre un valor mínimo correspondiente con la menor lectura posible del sensor y el valor máximo, que corresponde a la mayor temperatura que permite medir el sensor. Una función abstracta que nos sea útil es aquella que al llamarla nos regresaría el valor de la temperatura en grados celsuis. Para quien la llama no le importa si el valor máximo es 5 V o si es 3 V, porque la lógica detrás de la conversión se encuentra en la función, por lo que podríamos cambiar el sensor y sólo modificar ésta.
- Una vez construida la interfaz entre el software y el hardware, pasemos a la lógica de negocios. Ahora será necesario para nosotros construir funciones que estén más relacionadas con la actividad a realizar. En este caso, podríamos definir una función mover, que al ser llamada con una velocidad y dirección como argumentos, llamaría a su vez a las funciones de motores de la capa de infraestructura de tal manera que nos permitiera avanzar en la dirección deseada con la velocidad deseada, sin preocuparse de qué motor se utiliza.
- Posteriormente, construiríamos nuestra RobotAPI. Ésta constaría de todas aquellas funciones que nos permitieran saber el estado del sistema, en este caso las lecturas (útiles) de los sensores, aquellas que nos permitieran modificar algún parámetro del sistema, por ejemplo, a qué región de lecturas de un sensor infrarojo corresponde un color blanco y a qué un color negro. Finalmente, están aquellas que nos permitieran realizar alguna acción, como la anteriormente definida, mover.
- Para terminar, definimos qué tipo y protocolo de comunicación se tendrá con el mundo exterior (RF, Bluetooth, WiFi, RS232, USB), y construimos una interfaz en un dispositivo compatible con dicho protocolo para observar el proceso o dispositivo trabajando, y si es el caso, modificar su operación.
¿Cuáles son los beneficios de hacerlo así? Si se trata de un ejercicio académico que no recibirá mayor atención después de entregado, entiendo que sea difícil encontrarle utilidad al procedimiento mencionado. En cambio, si se trata de un sistema de manufactura, es importante que así sea, puesto que no se trata de un sistema desechable, sino de uno cuyo desempeño debe ser medido al segundo y debe permanecer operando continuamente el mayor tiempo posible, en un esquema a largo plazo donde deben contemplarse repuestos de máquinas, máquinas nuevas y distintas a las que fueron consideradas en el proceso de diseño, y sobre todo, aquellas situaciones imprevistas.
¿Qué piensan ustedes?
No hay comentarios:
Publicar un comentario