Lo que hago

Un pinout parece una tabla de números de patilla. En realidad es la primera decisión de arquitectura del proyecto, y el sitio más barato tanto para acertar como para equivocarse.

Rellenarlo exige tres cosas a la vez. Las restricciones de mapeo del microcontrolador: qué periférico puede alcanzar físicamente qué patilla, cuáles están compartidas entre funciones, cuáles se gastan en una interfaz de depuración que vas a necesitar más adelante. La topología de la placa: qué conecta con qué, qué tiene que estar aislado de la red, y qué es capaz de rutar el layout sin una pista más larga de lo que tolera la señal. Y los requisitos funcionales y de seguridad del producto: qué señales pertenecen a una función de seguridad y por tanto no pueden compartir recurso con nada más, porque compartirlo significaría que un solo fallo se lleva las dos por delante.

Si está bien, el equipo de firmware hereda una placa que le deja trabajar. Si está mal, aparece meses después, cuando la PCB ya existe, el utillaje está pagado, y el único arreglo posible es un parche por software que alguien va a mantener durante toda la vida del producto.

Esa asimetría es el argumento entero. No es una tarea de programador, es una tarea de arquitectura que, casualmente, se escribe en forma de tabla, y es la razón por la que la he hecho en todos los proyectos en los que he sido desarrollador líder desde 2017.

Calibrar un lazo de temperatura es la parte de mi trabajo que más se parece a la carrera, y la que más me gusta.

La cavidad es la planta, y es lenta: minutos de retardo puro, y una respuesta que cambia con la función de calentamiento seleccionada y con el tamaño de la cavidad. Ajustar el PID a base de prueba y error sobre el aparato real cuesta horas por intento y da un número que solo vale para una configuración.

Así que no ajusto sobre el aparato. Primero un ensayo en lazo abierto: escalones crecientes de potencia, cada uno mantenido hasta que la temperatura se estabiliza, todo registrado. Después, un modelo de primer orden con retardoFOPDTPrimer orden con retardo: un modelo matemático sencillo de cómo responde un sistema físico lento, que sirve para ajustar el lazo de control antes de tocar el aparato real. ajustado a esa respuesta, con un método numérico y no leyendo la curva a ojo, para que el resultado sea repetible y otra persona pueda reproducirlo. Después el lazo se ajusta en simulación contra ese modelo, sobre un simulador que ejecuta el mismo código de control que el producto. Solo la corrección final ocurre sobre el aparato real.

La parte que no está en el libro es el criterio de aceptación. Las reglas clásicas de ajuste optimizan para un sobreimpulso pequeño; los fabricantes de electrodomésticos quieren un calentamiento rápido y, a cambio, aceptan siempre un pequeño sobreimpulso. Así que los coeficientes se sesgan hacia la velocidad, deliberadamente, y eso es una decisión de producto disfrazada de ingeniería de control.

Escribí los scripts, fijé el método y luego lo entregué. Desde entonces lo han usado otros ingenieros, en productos que yo no desarrollé, que es la única prueba real de si aquello era un método o simplemente algo que se me daba bien.

El malentendido más común sobre mi trabajo es creer que el control electrónico certifica el aparato. No lo hace. Certifica una parte, y el fabricante del electrodoméstico completa el resto. Alguien tiene que decidir exactamente dónde cae esa línea, escribirlo, y luego defenderlo en las dos direcciones.

El ejemplo más claro que conozco es la limpieza pirolítica. Durante un ciclo de pirólisis un horno trabaja muy por encima de cualquier temperatura de cocinado y la puerta tiene que permanecer bloqueada. Bloquearla es responsabilidad del control: la función de seguridad, su implementación Class B, sus modos de fallo y la evidencia de todo eso son míos. La fuerza que ese bloqueo tiene que aguantar no: eso es mecánico, pertenece al aparato, y es del fabricante especificarlo y demostrarlo.

Ninguna de las dos mitades es segura por sí sola. Un bloqueo que no falla nunca, sobre un pestillo que cede, es un control certificado en un aparato inseguro, y ese es justo el hueco que se abre cuando cada lado da por hecho, en silencio, que el otro lo había cubierto.

Leer la norma es la parte fácil de esto. Saber qué cláusula es la tuya, y ser capaz de decírselo a un cliente que preferiría que cayera de tu lado, es la verdadera habilidad.

Una certificación tiene un alcance, y el alcance es un documento y no una sensación. Así que la pregunta útil ante cualquier cambio no es "¿esto es arriesgado?", sino "¿cae dentro de lo que se evaluó, y sigue valiendo la evidencia?".

Dos cambios que de lejos parecen iguales caen a lados opuestos de esa línea. Cambiar el algoritmo que lleva el sistema a estado seguro toca la función certificada: hay que reevaluarlo, volver a documentarlo y presentarlo otra vez. Cambiar el valor de un umbral con el que ese mismo algoritmo compara, dentro de un rango que ya se evaluó, no.

Lo primero cuesta meses y una tasa de certificación. Lo segundo es un parámetro. Saber cuál es cuál es lo que hace viable una línea de producto, porque es la diferencia entre ofertar un desarrollo nuevo y ofertar una variante de uno que ya existe. Es un criterio técnico con consecuencia comercial inmediata, y uno de los pocos sitios donde mi respuesta decide si algo llega a venderse.

La misma disciplina funciona en el otro sentido, y esa dirección es más incómoda. Un valor nominal de una hoja de características no es una especificación validada. Si un componente admite una cifra sobre el papel y el producto solo se ensayó con otra, la que cuenta es la ensayada, y decirlo mientras alguien espera para ofertar es parte del trabajo.

La arquitectura en este campo es un puñado de decisiones caras de revertir, todas tomadas cuando todavía no hay nada que mirar.

Dónde vive la inteligencia. Un producto con una placa de potencia y una de interfaz de usuario puede poner la lógica en cualquiera de las dos, o en las dos. Una interfaz que solo dibuja lo que le dicen es más barata de cambiar y concentra el riesgo en un sitio; una que piensa por sí misma sobrevive a un enlace lento y permite desarrollar las dos mitades en paralelo. Las dos son defendibles. Lo que no es defendible es acabar en una de ellas sin haberlo decidido nunca.

Qué es hardware y qué es software. Parte de esa frontera la fija la norma de seguridad, parte el coste, y parte qué lado del proyecto tiene capacidad este año. Esto último es un dato de entrada real, y las arquitecturas que fingen lo contrario no llegan a construirse.

Cómo se hablan las placas entre sí. Donde el enlace entre placas es propietario, diseñé el mediador que permite que cada módulo de software sea dueño de las tramas de su propio periférico, en vez de acumular el protocolo de todos ellos en un único archivo. Esa es la diferencia entre un protocolo que puedes ampliar y uno que reescribes.

Qué varía entre modelos. Una familia de producto no son N firmwares distintos. Trabajo con una técnica que mantiene un firmware base único y desplaza a una tabla de parámetros todo lo específico de cada modelo, de modo que un modelo nuevo es un archivo de datos y no una bifurcación, y una función nueva se implementa una sola vez.

Un problema de arquitectura que a primera vista no parece técnico: qué tiene que cambiar cuando un producto hecho para un solo cliente empieza a ofrecerse a varios.

Físicamente, nada. Lo que cambia es que cada suposición que se dio por buena para el cliente original se convierte en una restricción. El tipo de sensor. Los umbrales de conmutación. La corriente para la que se validó la salida. Y la certificación, que se concedió con la aplicación de un fabricante concreto detrás.

Convertir eso en una plataforma es sobre todo una cuestión de alcance, planteada suposición a suposición: ¿esto es un parámetro o es diseño, y qué dice la certificación sobre moverlo? Aquí es donde el criterio de recertificación de más arriba se paga solo. Si un cambio se queda dentro del alcance evaluado, un cliente nuevo es una variante, un cambio de software y una actualización de certificación. Si no, lo que estás ofertando es un desarrollo, y hay que decirlo cuanto antes.

Ese trabajo lo hice como autoridad técnica del producto sin escribir una línea de su firmware, que es la evidencia más limpia que tengo de que este rol es separable de la implementación. El ingeniero que sí la escribió es aquel a quien yo había enseñado a definir un pinout.

Las especificaciones de cliente llegan en todas las formas posibles, y la distinción útil no es entre buenas y malas. Es qué clase de problema es cada una.

Equivocada en el detalle, acertada en la intención. Son las baratas. Implementas la intención, escribes qué hiciste en su lugar y por qué, consigues que se apruebe y sigues.

Ambigua o contradictoria, que es el caso habitual. Una especificación escrita como un manual de usuario describe cómo debería verse el aparato por fuera y deja el comportamiento implícito, así que cada lector rellena los huecos a su manera y los huecos solo aparecen en integración. La respuesta no es quejarse del documento, es producir el que falta: la máquina de estados a nivel de sistema, redactada como documento de diseño y devuelta como propuesta. Por mi experiencia, se adopta, y a partir de ahí es la referencia contra la que discuten los dos lados, que vale bastante más que haber tenido razón.

Imposible a ese coste, en ese plazo o dentro de esa certificación. Estas piden una contrapropuesta, nunca una negativa: qué puedo hacer, qué cuesta, qué necesito a cambio y qué evidencia respalda el número. Un no con una alternativa detrás es una negociación. Un no a secas es un escalado, y se escalará por encima de mí.

Y a veces la especificación está bien y el equivocado soy yo. Decirlo pronto sale más barato que defender la posición, y me da el crédito que necesito para las veces en que no lo estoy.

Antes de que exista un proyecto hay una oferta, y una oferta necesita ingeniería detrás.

Lo que aporto ahí: si un microcontrolador dado y un concepto de control dado pueden sostener de verdad el producto que se está pidiendo; el contenido técnico de la oferta, para que lo que se promete sea lo que se puede construir; muestras a medida definidas contra los puntos de trabajo reales del cliente y no contra los de catálogo; y diagnóstico cuando vuelve una muestra reportada como defectuosa, que la mitad de las veces resulta ser cómo la cablearon para el ensayo.

No todo acaba en pedido, y esa es la forma normal de este trabajo. La decisión de invertir en un desarrollo no es una decisión de ingeniería, y el cierre no me corresponde apuntármelo. Lo que sí es mío es que la respuesta técnica que recibió el cliente fuera exacta, incluidas las veces en que la respuesta exacta era que el producto actual no encaja sin un rediseño.

La gestión de requisitos se vende como trazabilidad y se compra como cumplimiento, y en la distancia entre esas dos cosas es donde fracasan las implantaciones.

Lo que se obtiene cuando funciona es una cadena que puedes recorrer en las dos direcciones: de una línea de la especificación del cliente, al requisito de sistema que la interpreta, al diseño que lo implementa, al ensayo que lo demuestra, y de vuelta. Cuando un cliente pregunta por qué el producto se comporta así, o un certificador pregunta qué evidencia cubre una función, la respuesta es una consulta y no una excavación arqueológica.

Lo que cuesta no es la licencia. Cada requisito tiene que escribirlo alguien que entienda a la vez la intención del cliente y el sistema, y eso es tiempo de ingeniería que no produce código. Las baselines tienen que ser reales, es decir, con diagramas y adjuntos congelados junto al texto y no simplemente referenciados, o la baseline es una foto que no retrata nada. Las dos cosas son invisibles en una demo de herramienta e inevitables en la práctica.

Por qué fracasan las implantaciones, por haber visto una de cerca: la herramienta se elige antes de recoger las necesidades; el proceso viene del proveedor en lugar de salir de cómo trabajan los equipos; y la migración se hace antes de que nadie haya validado que los datos migrados son correctos. Cada una de las tres es evitable, y las tres se evitan con el mismo gesto impopular, que es estar dispuesto a defender una fecha más tardía. Esa defensa la he hecho por escrito, y la volvería a hacer.

Dos cosas, en este orden, y el orden es lo importante.

Definición de pinout. No cómo se rellena la tabla, que es una tarde, sino por qué la tabla es una decisión de arquitectura: qué fija, quién depende de ello y qué cuesta cambiarlo cuando ya existe una placa. Un ingeniero que ha entendido eso ha entendido la frontera entre hardware y software, y ahí está casi todo lo que separa escribir firmware de responder de un producto.

Teoría de termopares, y en concreto la compensación de junta fríacompensación de junta fríaUn termopar mide una diferencia de temperatura, así que para obtener una lectura absoluta hace falta la temperatura del otro extremo del hilo, y hay que corregir por ella.. Es el ejemplo más limpio que conozco de un problema que no se puede resolver desde dentro del firmware. Estás compensando con una temperatura medida en algún punto de la placa, y si hay un gradiente térmico en esa placa, la temperatura con la que compensas no es la de la junta. No hay código que lo arregle. Hay que tener el sensor, el circuito y el layout en la cabeza al mismo tiempo. En cuanto alguien ha visto un fallo con esa forma, deja de buscar la causa solo dentro de su propio archivo.

Todo lo demás pueden sacarlo del código.