Que es realmente un codeplug

Un codeplug es el archivo de programación que define como se comporta un radio. No es el firmware ni es el hardware. Es la capa de configuración que se ubica encima de ambos y le indica al radio en que puede transmitir y como. Cuando se conecta un radio a una computadora de programación, se lee y se guarda el resultado, ese archivo guardado es el codeplug de ese radio en ese momento.

Dentro de un codeplug tipico se encuentran varios tipos de configuraciones que trabajan juntas:

• Canales. Cada canal contiene una frecuencia de transmisión y recepción o un slot digital, junto con el tono o codigo de color que evita que el radio se abra con tráfico que no le corresponde.
• Zonas. Las zonas son grupos de canales organizados para que un usuario pueda girar una perilla o presionar un botón y llegar al conjunto correcto. Un plan de zonas bien construido refleja como las cuadrillas realmente piensan su día.
• Talkgroups. En sistemas trunked y digitales, los talkgroups son los canales logicos que enrutan el tráfico a las personas correctas. El canal físico apunta a un talkgroup en lugar de a una sola frecuencia fija.
• Tonos y códigos. Los tonos de squelch, los códigos de color y los identificadores de red controlan quien escucha a quien y evitan que sistemas vecinos se mezclen entre si.
• Configuraciones del radio. Los niveles de potencia, las listas de escaneo, las asignaciones de botones, las etiquetas de pantalla, el comportamiento de emergencia y los ajustes de audio también viven en el codeplug.

Debido a que cada uno de estos elementos se puede editar de forma independiente, un codeplug es fácil de cambiar y fácil de cambiar mal. Esa es la razón completa por la cual la gestión importa. El archivo es poderoso, y el poder sin un proceso se desfasa.

Por qué importa la consistencia de la flota

La consistencia no es una preferencia de orden. Es una función de seguridad operativa. Dos cosas se rompen en el momento en que los radios dejan de coincidir.

Primero, se rompe la intercambiabilidad. La promesa de una flota es que cualquier miembro puede tomar cualquier radio y este se comportara exactamente igual que el que llevaba ayer. El canal tres debe ser el canal tres en cada unidad. La zona dos debe contener los mismos canales para todos. Si un radio tiene una lista de escaneo diferente o un canal en una posición distinta, un miembro que busca una posición de perilla familiar bajo presión termina en un lugar que no pretendia.

Segundo, se rompe la coordinación de mando. Cuando un oficial ordena un cambio a un canal específico por nombre, esa orden solo funciona si cada radio dentro del alcance de escucha tiene ese canal, etiquetado de la misma manera, en una posición que la gente pueda encontrar. Si la mitad de la flota lo llama de una forma y la otra mitad de otra, o si algunos radios nunca recibieron el canal, la instrucción del oficial llega de manera distinta según la unidad. Esa es exactamente la situación que una buena programación debe evitar.

La plantilla maestra como fuente de verdad

El hábito más importante en la gestión de codeplugs es mantener una sola plantilla maestra de la cual desciende cada radio de una clase. La maestra es la definición de lo correcto. Los radios individuales son copias de ella, ajustados solo en el pequeño número de cosas que realmente deben diferir entre unidades.

La mayoría de las flotas necesitan más de una maestra porque no todos los radios son identicos. Un radio móvil montado en una unidad tiene necesidades distintas a las de un portátil que se lleva en el cinturón. Un radio asignado a un rol puede llevar zonas que otro rol nunca usa. El enfoque correcto es un conjunto pequeño y deliberado de maestras, una por cada categoría real, en lugar de un archivo hecho a mano por separado para cada número de serie.

Lo que pertenece a la maestra y lo que no:

• En la maestra: el plan de canales, la distribución de zonas, las asignaciones de talkgroups, los tonos y códigos, las listas de escaneo, las asignaciones de botones, las etiquetas de pantalla y el comportamiento estándar del radio. Todo lo que debería ser idéntico dentro de la clase.
• Ajustado por radio: el identificador o alias individual del radio si el sistema usa uno, y cualquier direccionamiento fisicamente único. Estos son los unicos campos que deberían diferir, y deberían diferir de manera documentada y predecible.

Cuando un radio nuevo se une a la flota o uno viejo se reprograma, no se construye de memoria. Se carga la maestra vigente para su clase, se aplica el pequeño ajuste por unidad, y ya esta listo. Un radio programado de esta manera es correcto por construcción porque hereda la corrección de la plantilla.

Control de versiones y gestión de cambios

Una plantilla maestra no es un objeto estatico. Los sistemas cambian, se agregan talkgroups, se reajustan tonos y se limpian etiquetas. La maestra tiene que cambiar con ellos, y ahí es donde el control de versiones se gana su lugar.

El control de versiones para codeplugs no requiere software especial. Requiere disciplina y una convención de nombres. El objetivo es que cualquier persona pueda ver un archivo y saber exactamente que es, cuando se hizo y si esta vigente.

• Versione cada maestra. Asigne a cada versión un número y una fecha. Cuando cambie la maestra, genere una versión nueva en lugar de sobrescribir la anterior. Las versiones anteriores se quedan en el archivo para que siempre pueda ver que tenía cargado un radio programado la primavera pasada.
• Nombre los archivos para que se describan solos. Un nombre de archivo que incluya la clase del radio, la versión y la fecha le dice lo que necesita saber antes de abrirlo. Evite nombres como “final” o “más reciente”, que dejan de ser ciertos en el momento en que llega el siguiente cambio.
• Mantenga un registro de cambios. Lleve un documento continuo que registre, para cada versión, que cambio, por qué, quien hizo el cambio y la fecha. Cuando alguien pregunte por qué se movio un canal, la respuesta debería ser una línea en un registro y no una suposición.
• Respalde cada archivo. Tanto las plantillas maestras como las lecturas individuales de cada radio merecen respaldos en más de un lugar. Un archivo de codeplugs que solo vive en una laptop de programación está a un cafe derramado de distancia de un fin de semana muy largo.

La gestión de cambios es el proceso humano alrededor de esos archivos. Antes de que un cambio entre a una maestra, alguien debe decidir que está justificado, probarlo en un solo radio y confirmar que funciona en el aire antes de que se convierta en el nuevo estándar para toda la clase. Los cambios fluyen en una sola dirección: de una propuesta, a una prueba, a una nueva versión de la maestra, a la flota. No comienzan en radios al azar en el campo para luego abrirse camino hacia atras dentro del estándar.

Como los cambios aislados provocan desfase

El desfase casi nunca ocurre a propósito. Ocurre a través de pequeños cambios bien intencionados que nunca regresan a la maestra. Un miembro reporta una etiqueta difícil de leer, entonces alguien la corrige en ese radio. Una cuadrilla necesita un canal para un evento temporal, y este se agrega a las unidades de esa asignación. Cada cambio resuelve un problema real en el momento. Ninguno de ellos está mal por si solo. Juntos, a lo largo de un año, convierten una flota uniforme en una colección de casos aislados.

El peligro de un cambio aislado es que solo vive en el radio donde se hizo. La maestra no sabe de el, entonces la próxima vez que ese radio se reprograme desde la maestra, el cambio desaparece y el problema que resolvia regresa. Peor aun, si el cambio era bueno y debio haberse aplicado a toda la flota, solo unos pocos radios lo recibieron, y ahora la flota está dividida.

La solución no es prohibir los cambios en campo. Las cuadrillas a veces necesitan un cambio rápido, y negarse no es realista. La solución es que cada cambio en campo se capture y se concilie. O bien pasa a la siguiente versión de la maestra, o se registra como una excepción conocida por unidad. Nada se queda como una diferencia silenciosa e invisible.

Contraseñas y protección de lectura/escritura

Los codeplugs suelen contar con alguna forma de protección de acceso para que el archivo y el radio no puedan leerse o reescribirse de manera casual por cualquiera que tenga un cable. Usada bien, esta protección resguarda el estándar frente a cambios accidentales y protege el archivo mismo de ser copiado desde un radio perdido. Esta sección se mantiene a nivel de política, no de técnica, y nada aquí se refiere a superar la protección de un equipo que no le pertenece.

Las prácticas de gestión que vale la pena adoptar:

• Decida quien puede programar. El acceso a la programación debería recaer en un grupo pequeño y capacitado, en lugar de estar abierto a cualquiera que tenga un cable. Menos manos sobre la maestra significa menos oportunidades de cambios sin coordinar.
• Trate las credenciales de protección como información controlada. Guardelas de la misma manera en que guarda cualquier credencial operativa sensible, en un lugar seguro y limitado, no escritas en la laptop de programación ni pegadas dentro de un gabinete.
• Mantenga la protección uniforme en toda la flota. Si algunos radios están protegidos y otros no, los que no lo están se convierten en el camino fácil para cambios sin documentar, que es exactamente el desfase que se quiere evitar.
• No pierda su propio acceso. Como la protección puede bloquear un archivo, la perdida de sus credenciales puede ser tan perjudicial como la perdida de los archivos mismos. Guarde la información de recuperación bajo el mismo proceso controlado que usa para el archivo.

El objetivo de la protección es hacer que el estándar sea difícil de cambiar por accidente y fácil de cambiar a propósito a través de las personas correctas. Es un candado en la puerta principal, no un sustituto de saber quien entra y quien sale.

Coordinar la programación en toda la flota

Programar un radio es una tarea. Programar toda una flota, y mantenerla programada correctamente después de un cambio de sistema, es un proyecto. La diferencia está en la coordinación.

Los momentos que más exigen coordinación son los cambios de sistema. Cuando el sistema de radio en el que opera cambia un talkgroup, reajusta un tono, agrega un canal o reorganiza algo de lo que dependen sus radios, cada radio afectado en su flota tiene que actualizarse. Si actualiza algunos y se le escapan otros, ha fabricado desfase en una sola tarde, y es un desfase con consecuencias reales porque los radios que se pasaron por alto pueden dejar de alcanzar el tráfico que necesitan.

Un enfoque de coordinación viable se ve así:

• Este atento a los cambios a nivel de sistema. Manténgase en contacto con quien administra el sistema más amplio para enterarse de los cambios antes de que entren en vigor, no después de que una cuadrilla reporte un canal muerto.
• Actualice la maestra primero. Cuando llegue un cambio de sistema, integrelo en una nueva versión de la maestra y pruebela en el aire antes de tocar la flota. La flota hereda la corrección de una maestra ya comprobada.
• Registre que radios están actualizados. Mantenga una lista de cada radio de la flota y marque cada uno a medida que se lleva a la versión vigente. Un radio del que no puede dar cuenta es un radio que debe asumir como desactualizado.
• Atrape los que estaban fuera de servicio. Los radios en reparación, en un estante de repuestos o asignados a miembros que estaban de descanso durante la actualización son los que se pasan por alto. Cree un paso que revise esas unidades antes de que vuelvan a ponerse en rotación.

El mismo seguimiento que ayuda durante un cambio de sistema ayuda todos los días. Si siempre sabe que radio está en que versión de la maestra, nunca tiene que preguntarse si la flota es uniforme. Puede verlo.

Una rutina práctica y una lista de verificación

Todo lo anterior se junta en una rutina que se ejecuta con una cadencia regular y no solo en una crisis. Un ritmo constante evita que pequeñas diferencias se conviertan en grandes diferencias.

Una rutina razonable tiene tres capas. Con un calendario establecido, lea una muestra de radios y comparelos contra la maestra vigente para detectar el desfase temprano. Cada vez que un radio ingrese por cualquier motivo, verifique su versión antes de que vuelva a salir. Y cada vez que la maestra cambie, ejecute una actualización completa de la flota con seguimiento para que nada se pase por alto. Entre esos pasos, mantenga su archivo y su registro de cambios al día para que el rastro documental siempre coincida con los radios.

Use esta lista de verificación para mantener la práctica honesta:

• Mantenga un pequeño conjunto de plantillas maestras, una por cada clase real de radio, como la única fuente de verdad.
• Versione cada maestra con un número y una fecha, y nunca sobrescriba una versión anterior.
• Nombre los archivos para que la clase, la versión y la fecha sean visibles sin necesidad de abrirlos.
• Mantenga un registro de cambios que anote que cambio, por qué, quien y cuando para cada versión.
• Respalde las maestras y las lecturas individuales en más de una ubicación.
• Programe los radios nuevos y reprogramados a partir de la maestra vigente, ajustando solo los campos documentados por unidad.
• Capture cada cambio en campo y promuevalo a la maestra o registrelo como una excepción conocida.
• Límite el acceso a la programación a un grupo pequeño y capacitado, y controle las credenciales de protección como información sensible.
• Mantenga un listado de flota que registre la versión actual de la maestra de cada radio.
• Ante cualquier cambio de sistema, actualice primero la maestra, pruebela en el aire y luego revise toda la flota con seguimiento.
• Incluya los radios fuera de servicio, de repuesto y de miembros fuera de turno en cada revisión de actualización antes de que regresen a rotación.
• Realice revisiones puntuales programadas que comparen los radios en uso contra la maestra para detectar el desfase temprano.

Nada de esto requiere herramientas exoticas. Requiere una fuente de verdad, registros honestos y la disciplina de encaminar cada cambio a través de la maestra en lugar de aplicarlo a radios individuales. Haga esto de manera constante y su flota seguira siendo una flota: intercambiable, predecible y lista para el momento en que un miembro tome un radio sin pensarlo dos veces y este simplemente funcione.