Programacion de Radios y Gestion de Codeplugs: Mantener una Flota Consistente

Que es realmente un codeplug

Un codeplug es el archivo de programacion que define como se comporta un radio. No es el firmware ni es el hardware. Es la capa de configuracion 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 programacion, 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 transmision y recepcion o un slot digital, junto con el tono o codigo de color que evita que el radio se abra con trafico que no le corresponde.
• Zonas. Las zonas son grupos de canales organizados para que un usuario pueda girar una perilla o presionar un boton y llegar al conjunto correcto. Un plan de zonas bien construido refleja como las cuadrillas realmente piensan su dia.
• Talkgroups. En sistemas trunked y digitales, los talkgroups son los canales logicos que enrutan el trafico a las personas correctas. El canal fisico apunta a un talkgroup en lugar de a una sola frecuencia fija.
• Tonos y codigos. Los tonos de squelch, los codigos 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 tambien viven en el codeplug.

Debido a que cada uno de estos elementos se puede editar de forma independiente, un codeplug es facil de cambiar y facil de cambiar mal. Esa es la razon completa por la cual la gestion importa. El archivo es poderoso, y el poder sin un proceso se desfasa.

Por que importa la consistencia de la flota

La consistencia no es una preferencia de orden. Es una funcion 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 posicion distinta, un miembro que busca una posicion de perilla familiar bajo presion termina en un lugar que no pretendia.

Segundo, se rompe la coordinacion de mando. Cuando un oficial ordena un cambio a un canal especifico por nombre, esa orden solo funciona si cada radio dentro del alcance de escucha tiene ese canal, etiquetado de la misma manera, en una posicion 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 instruccion del oficial llega de manera distinta segun la unidad. Esa es exactamente la situacion que una buena programacion debe evitar.

La plantilla maestra como fuente de verdad

El habito mas importante en la gestion de codeplugs es mantener una sola plantilla maestra de la cual desciende cada radio de una clase. La maestra es la definicion de lo correcto. Los radios individuales son copias de ella, ajustados solo en el pequeno numero de cosas que realmente deben diferir entre unidades.

La mayoria de las flotas necesitan mas de una maestra porque no todos los radios son identicos. Un radio movil montado en una unidad tiene necesidades distintas a las de un portatil que se lleva en el cinturon. Un radio asignado a un rol puede llevar zonas que otro rol nunca usa. El enfoque correcto es un conjunto pequeno y deliberado de maestras, una por cada categoria real, en lugar de un archivo hecho a mano por separado para cada numero de serie.

Lo que pertenece a la maestra y lo que no:

• En la maestra: el plan de canales, la distribucion de zonas, las asignaciones de talkgroups, los tonos y codigos, las listas de escaneo, las asignaciones de botones, las etiquetas de pantalla y el comportamiento estandar del radio. Todo lo que deberia ser identico dentro de la clase.
• Ajustado por radio: el identificador o alias individual del radio si el sistema usa uno, y cualquier direccionamiento fisicamente unico. Estos son los unicos campos que deberian diferir, y deberian 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 pequeno ajuste por unidad, y ya esta listo. Un radio programado de esta manera es correcto por construccion porque hereda la correccion de la plantilla.

Control de versiones y gestion 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 ahi es donde el control de versiones se gana su lugar.

El control de versiones para codeplugs no requiere software especial. Requiere disciplina y una convencion 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 version un numero y una fecha. Cuando cambie la maestra, genere una version nueva en lugar de sobrescribir la anterior. Las versiones anteriores se quedan en el archivo para que siempre pueda ver que tenia 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 version y la fecha le dice lo que necesita saber antes de abrirlo. Evite nombres como "final" o "mas 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 version, que cambio, por que, quien hizo el cambio y la fecha. Cuando alguien pregunte por que se movio un canal, la respuesta deberia ser una linea en un registro y no una suposicion.
• Respalde cada archivo. Tanto las plantillas maestras como las lecturas individuales de cada radio merecen respaldos en mas de un lugar. Un archivo de codeplugs que solo vive en una laptop de programacion esta a un cafe derramado de distancia de un fin de semana muy largo.

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

Como los cambios aislados provocan desfase

El desfase casi nunca ocurre a proposito. Ocurre a traves de pequenos cambios bien intencionados que nunca regresan a la maestra. Un miembro reporta una etiqueta dificil 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 asignacion. Cada cambio resuelve un problema real en el momento. Ninguno de ellos esta mal por si solo. Juntos, a lo largo de un ano, convierten una flota uniforme en una coleccion 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 proxima 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 esta dividida.

La solucion no es prohibir los cambios en campo. Las cuadrillas a veces necesitan un cambio rapido, y negarse no es realista. La solucion es que cada cambio en campo se capture y se concilie. O bien pasa a la siguiente version de la maestra, o se registra como una excepcion conocida por unidad. Nada se queda como una diferencia silenciosa e invisible.

Contrasenas y proteccion de lectura/escritura

Los codeplugs suelen contar con alguna forma de proteccion 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 proteccion resguarda el estandar frente a cambios accidentales y protege el archivo mismo de ser copiado desde un radio perdido. Esta seccion se mantiene a nivel de politica, no de tecnica, y nada aqui se refiere a superar la proteccion de un equipo que no le pertenece.

Las practicas de gestion que vale la pena adoptar:

• Decida quien puede programar. El acceso a la programacion deberia recaer en un grupo pequeno 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 proteccion como informacion 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 programacion ni pegadas dentro de un gabinete.
• Mantenga la proteccion uniforme en toda la flota. Si algunos radios estan protegidos y otros no, los que no lo estan se convierten en el camino facil para cambios sin documentar, que es exactamente el desfase que se quiere evitar.
• No pierda su propio acceso. Como la proteccion puede bloquear un archivo, la perdida de sus credenciales puede ser tan perjudicial como la perdida de los archivos mismos. Guarde la informacion de recuperacion bajo el mismo proceso controlado que usa para el archivo.

El objetivo de la proteccion es hacer que el estandar sea dificil de cambiar por accidente y facil de cambiar a proposito a traves de las personas correctas. Es un candado en la puerta principal, no un sustituto de saber quien entra y quien sale.

Coordinar la programacion en toda la flota

Programar un radio es una tarea. Programar toda una flota, y mantenerla programada correctamente despues de un cambio de sistema, es un proyecto. La diferencia esta en la coordinacion.

Los momentos que mas exigen coordinacion 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 trafico que necesitan.

Un enfoque de coordinacion viable se ve asi:

• Este atento a los cambios a nivel de sistema. Mantengase en contacto con quien administra el sistema mas amplio para enterarse de los cambios antes de que entren en vigor, no despues de que una cuadrilla reporte un canal muerto.
• Actualice la maestra primero. Cuando llegue un cambio de sistema, integrelo en una nueva version de la maestra y pruebela en el aire antes de tocar la flota. La flota hereda la correccion de una maestra ya comprobada.
• Registre que radios estan actualizados. Mantenga una lista de cada radio de la flota y marque cada uno a medida que se lleva a la version 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 reparacion, en un estante de repuestos o asignados a miembros que estaban de descanso durante la actualizacion son los que se pasan por alto. Cree un paso que revise esas unidades antes de que vuelvan a ponerse en rotacion.

El mismo seguimiento que ayuda durante un cambio de sistema ayuda todos los dias. Si siempre sabe que radio esta en que version de la maestra, nunca tiene que preguntarse si la flota es uniforme. Puede verlo.

Una rutina practica y una lista de verificacion

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 pequenas 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 version antes de que vuelva a salir. Y cada vez que la maestra cambie, ejecute una actualizacion 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 dia para que el rastro documental siempre coincida con los radios.

Use esta lista de verificacion para mantener la practica honesta:

• Mantenga un pequeno conjunto de plantillas maestras, una por cada clase real de radio, como la unica fuente de verdad.
• Versione cada maestra con un numero y una fecha, y nunca sobrescriba una version anterior.
• Nombre los archivos para que la clase, la version y la fecha sean visibles sin necesidad de abrirlos.
• Mantenga un registro de cambios que anote que cambio, por que, quien y cuando para cada version.
• Respalde las maestras y las lecturas individuales en mas de una ubicacion.
• 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 excepcion conocida.
• Limite el acceso a la programacion a un grupo pequeno y capacitado, y controle las credenciales de proteccion como informacion sensible.
• Mantenga un listado de flota que registre la version 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 revision de actualizacion antes de que regresen a rotacion.
• 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 traves 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.