Revisiones y cambios
¿Qué se congela cuando liberas una tarjeta?
Tus ficheros siguen siendo editables tras liberar, así que una línea base es una promesa, no un cerrojo. Qué lleva, las tres formas de congelar y el mínimo útil.
Tus ficheros siguen siendo editables después de liberarlos. Nada en tu ordenador te impide abrir el esquema a la mañana siguiente y mover una resistencia.
¿Qué significa entonces «congelado»?
Significa una promesa: que un conjunto con nombre, con cada elemento en una revisión declarada, no cambiará bajo ese nombre. Quien vuelva a ese nombre más adelante encontrará lo mismo. Rompe la promesa una vez y el nombre deja de significar nada, y ése es todo el mecanismo: una línea base no tiene ninguna imposición técnica detrás, sólo la disciplina de no editar algo que dijiste que no ibas a editar.
Suena débil. En la práctica es la columna vertebral de cualquier proyecto de hardware que funcione, porque es lo que hace que una frase como «entregamos la Rev C» transporte información.
Para qué sirve una línea base
Para tres cosas, y conviene tener claro cuál necesitas, porque llevan a contenidos algo distintos.
Reproducir. Alguien tiene que volver a fabricar lo mismo, quizá dentro de dos años. La línea base tiene que contener todo lo necesario para producirlo.
Comparar. Algo ha fallado, y la pregunta es en qué se diferencia el lote que funcionaba del que no. La línea base tiene que ser comparable, es decir, consistente en su forma entre entregas.
Responder. Alguien aprobó esta configuración para un fin. La línea base tiene que registrar quién, cuándo y para qué.
La mayoría de los equipos escriben líneas base para reproducir, y luego se molestan cuando no pueden responder a las otras dos.
Qué lleva dentro
| Elemento | Por qué tiene que estar |
|---|---|
| Esquema, en una revisión declarada | La intención |
| Layout, en una revisión declarada | El diseño físico |
| Salidas de fabricación | Lo que recibió realmente el fabricante |
| BOM, en una revisión declarada | Qué se monta |
| Plano de montaje | Lo que necesita una persona |
| Compilación de firmware, con versión | Sin él las tarjetas no funcionan |
| Procedimiento y límites de ensayo | Cómo se definía «bueno» entonces |
| El registro de liberación | Quién aprobó, cuándo y para qué |
Y unas cuantas cosas que se olvidan:
Datos de librería o de huellas, si viven fuera del proyecto y pueden cambiar por debajo. Herramienta y versión, si volver a abrir el diseño depende de ello. Las alternativas aprobadas vigentes entonces: una tarjeta montada con la segunda fuente sigue siendo esa configuración, pero sólo si la línea base lo dice. Las desviaciones conocidas: todo lo aceptado como apartamiento del diseño.
Congelar son tres mecanismos, no uno
En la práctica los equipos congelan una entrega de una de tres maneras, y no son equivalentes.
Copiarla. Coges las salidas, las metes en una carpeta con el nombre de la entrega y no las vuelves a tocar. Sencillo, y funciona. Su debilidad es que la fuente sigue siendo editable, así que la copia se separa del proyecto del que salió y nadie se entera hasta que difieren.
Marcarla. Registras que la Rev C es la revisión liberada y sigues editando la fuente hacia la Rev D. Esto conserva una sola línea de histórico, que es mejor, pero depende por completo de que la marca sea honesta y de que nadie edite la Rev C después.
Registrarla. Guardar cada revisión como una cosa por derecho propio, de modo que la Rev C siga siendo recuperable pase lo que pase con la Rev D. Es lo que hace el control de versiones en software, y lo que hace un sistema PDM o PLM en hardware.
Casi todos los equipos pequeños usan el primero, pasan al segundo, y sólo adoptan el tercero cuando los dos primeros les han fallado de una forma que costó dinero. Esa progresión no tiene nada de malo, pero conviene saber en cuál te apoyas, porque cada uno falla de manera distinta.
El registro de liberación
Uses el mecanismo que uses, escribe el registro. Es una página y es la parte que sobrevive:
Entrega 2025-03-14 — Tarjeta principal ORION PCB Rev C · Tarjeta Rev 2 · BOM Rev 4 · Firmware 1.2.7 Finalidad: fabricación de producción, 500 unidades Cambios desde la entrega anterior: ECO-018 (regulador), ECO-019 (serigrafía) Aprobado: [nombre], 14 de marzo de 2025 Desviaciones vigentes: ninguna Ficheros:
/entregas/orion-tpc/2025-03-14/
Contenido de muestra. Las dos líneas que más trabajo hacen son finalidad y desviaciones vigentes. La finalidad impide que una línea base de prototipo se use para producción seis meses después. Las desviaciones impiden que un apartamiento conocido y aceptado se redescubra como un defecto.
Cuando hay que cambiar algo congelado
Pasará. Que una línea base congelada resulte estar mal no es razón para editarla a escondidas.
Tres respuestas legítimas:
Emitir una línea base nueva. Normal, correcto, un poco lento. Emitir una desviación contra la existente. Un apartamiento documentado y acotado —«sólo para esta fabricación, montar el condensador alternativo»— que deja la línea base intacta y deja constancia de la excepción. * Retirarla. Si la línea base es activamente peligrosa, márcala como sustituida y di por qué, para que quien encuentre la carpeta sepa que no debe fabricar desde ahí.
Lo que no es legítimo es editar los ficheros congelados. Hoy no cuesta nada y destruye el valor de todas las líneas base que vayas a crear, porque a partir de ahí nadie puede estar seguro de que ninguna esté intacta.
La versión más pequeña que merece la pena
Si esto suena pesado para un equipo de dos personas, el mínimo es de verdad pequeño:
- Una carpeta por entrega, con fecha y revisión en el nombre.
- Dentro, las salidas que fueron al proveedor, sin modificar.
- Un fichero de texto de una página con el registro de arriba.
- Una regla, escrita, de que nada de esa carpeta se edita nunca.
Eso es una tarde de preparación y responde a «¿qué fabricamos en marzo?» mientras sobreviva el disco. Todo lo demás son refinamientos.
El fallo que evita es concreto y frecuente: un proyecto donde los ficheros más nuevos son los únicos ficheros, donde cada entrega sobrescribió a la anterior, y donde la respuesta honesta a cualquier pregunta sobre una fabricación pasada es una reconstrucción a partir de la memoria y los pedidos de compra.
Cuánto de esto es manual depende de dónde vivan las revisiones. Si una revisión congelada es una carpeta copiada, la disciplina es enteramente tuya; si cada revisión se guarda como un registro propio, la congelación es una propiedad de los datos.
Es la parte de la que se ocupa XKEMA: la tarjeta y su BOM llevan cada una su histórico de versiones, de modo que una revisión anterior sigue siendo recuperable cuando ya existen las posteriores.
Gestión de configuración de hardware Checklist de liberación de una PCB * Control de revisiones hardware: guía práctica