You are on page 1of 17

Ingeniería Confinada a su Circunstancia:

Visión Empresarial, a los 40 años de Ejercicio Profesional


 PRÓLOGO

E
N febrero de 1971 se realizó mi Acto de Graduación como Ingeniero Electrónico en la
Pontifica Universidad Javeriana de Bogotá, y quiero compartir con mis amigos y alumnos,
en esta breve reseña, un resumen de algunos de mis logros personales en el ámbito
tecnológico, obtenidos durante estos cuarenta años de ejercicio profesional. Hay tanto qué
rememorar: los estudios lejos de mi hogar en Medellín, la graduación con honores, mis comienzos
como flamante profesor en la Facultad de Electrónica, mi matrimonio con Elízabeth Forero –mi
exalumna– Javeriana también; y esta larga y prolongada partida, lejos de mi terruño…

 PERSPECTIVA HISTÓRICA
Mi actividad profesional comenzó en febrero del 71 cuando, recién graduado, la Javeriana me
contrató a través de su decano Rodrigo Mejía, como profesor (3,5 años) de Sistemas Digitales para
hacer evolucionar esa área porque junto a mis compañeros de equipo, yo acababa de realizar un
aporte significativo al desarrollar el primer Computador Digital de la región, CODIDAC, como
trabajo de grado en Ingeniería Electrónica (cfr. uribe.tel, uribe.tk). Hacia 1974 comencé un periplo de
30 años que me llevó hasta el 2003 y en el que me desenvolví como: profesor también, en la USB
(4 años); Gerente Técnico en COASIN (DEC, 3 años), Gerente de Ventas (DTS, Intelligent POS
Terminals) en ECADAT (2 años)… y comencé al final mi última etapa, en el área de Proyectos,
primero como Ingeniero (ECADAT, 1982), luego como Gerente (AUTOTROL, 7 años, TRW, Ferranti)
y por último como Vicepresidente de Ingeniería de tres empresas donde tuve 25% de
participación accionaria: VESSING (4 años), Venezuelan Transmission & Distribution (VT&D, 4
años) y ElectriAhorro (4 años).

EDELCA, Electrificación del Caroní, Puerto Ordaz


Los primeros equipos comerciales en cuyo diseño participé, de relevancia digna de mención por
una apreciable cantidad de razones de índole técnica y estratégica, fueron 13 Registradores de
Fallas para EDELCA (trece eran todas sus subestaciones de Transmisión hacia 1986); esta actividad comenzó
como una actualización tecnológica para sus equipos marca Hathaway e incluyó el hardware que le
añadimos a sus unidades para reemplazar, por un dispositivo diseñado por nosotros en
AUTOTROL, el sistema óptico de impresión local, preexistente en sus unidades, y la instalación de
un PC Maestro con programación de nuestra manufactura, que leía permanentemente el estado de
los registradores y llevaba la información por vía telefónica hasta el centro de control para ponerla

1
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

automáticamente a la disposición del grupo técnico de análisis de fallas en Puerto Ordaz, donde
los ingenieros podían imprimirla localmente en papel común y corriente (a diferencia de los costosos
rollos del Hathaway original, de material fotosensible no disponibles en el mercado local), y que además ayudaba
a realizar los análisis directamente en el PC, empleando herramientas programáticas ad-hoc que
hicimos a tal fin. Nuestros fueron el diseño y el desarrollo completos de la Arquitectura del
Sistema: topología, protocolos, subsistema de comunicaciones, aplicaciones de análisis, subsistema
de impresión, en matriz de puntos y en dispositivos láser; aplicaciones para la localización de
fallas… y algunos aspectos más.

Terminado exitosamente ese proyecto nos preguntábamos qué le faltaría a esta solución para
convertirla en un sistema completo que fuera un producto nuestro, propio. Poca cosa, en realidad:
unidades conversoras de valores analógicos a digitales, conformadores y adecuadores de las
señales externas, fuentes de alimentación, gabinete... Así nació nuestro primer equipo de alta
tecnología, diseñado y construido completamente en el país: El Registrador Digital de Fallas, DFR.

Le tengo singular apego al proyecto de EDELCA porque fue como nuestro primogénito y nos permitió
dar un primer paso entre gigantes, sobre todo siendo esta empresa electrificadora, una compañía con
miras de ingeniería extraordinariamente elevadas, cuyas exigencias técnicas hacían que los productos y
soluciones avalados por ella, mediante la incorporación a sus proyectos y sistemas, fueran siempre de
altísima calidad y ofrecieran muy avanzadas y especiales prestaciones. Un gran privilegio y una extrema
fortuna fue haber contado con el apoyo de su personal, que para la época dio un voto de confianza a la
ingeniería electrónica local, creyó que en realidad podía desarrollarse por estas latitudes, tecnología
autóctona de calidad y de avanzada, y nos apadrinó –si así puede decirse– con su decisión de encarar
este proyecto, de lo cual nunca tampoco se arrepintieron pues, en reciprocidad, encontraron en nosotros
un grupo de profesionales que respondió desarrollando dispositivos superiores a los importados, lo que
puede constatarse detallando las mayores y más modernas funcionalidades que siempre otorgábamos, la
garantía de 5 años con que cubríamos todos nuestros productos (¿conoce usted algún otro producto que tenga
5 años de garantía? Ni para el matrimonio…) y con la manera fresca que teníamos de entender y atender
al cliente y sus necesidades, que siempre van más allá de ser un mero problema técnico puntual.

ENELVEN, Energía Eléctrica de Venezuela, Zulia


A pesar de la conveniencia táctica de profundizar en el mercado de los DFR, las veleidades del
destino (¡ cuándo no ! ) hicieron que se presentara una situación completamente diferente: ENELVEN,
habiéndose enterado con satisfacción, en reuniones atinentes al Sistema Eléctrico Interconectado,
del resultado de nuestro proyecto en EDELCA, solicitó que le suministráramos Unidades
Terminales Remotas (RTU) para supervisión y control de subestaciones eléctricas de su red de
distribución. Nunca estuve muy interesado en ese rubro porque el mercado local era reducido y ya
había en el país al menos una compañía que suplía RTUs, sin contar también con la presencia de las
empresas transnacionales que importaban sus equipos desde otras latitudes.
Pero la ocasión tocaba a la puerta, y no era cuestión de hacer oídos sordos y dejarla pasar, ahora
que se nos abría una vía expedita para incursionar como proveedores locales, alternativos, de
dispositivos de alta tecnología comercializados hasta entonces por empresas europeas,
sobresalientes, que habiendo vendido en el país sistemas Supervisión y Control SCADA (ASEA,

2
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

BROWN-BOVERY, fusionadas luego como ABB), ostentaban un monopolio sobre sus RTU que les
permitía imponer precios exagerados, en opinión del cliente, a la hora de ofertar expansiones a sus
sistemas, y también equipos de reemplazo.
Así que, contra toda predicción, entramos de la mano de la diosa Fortuna
en el desarrollo y suministro local de RTUs.

ELECTRICIDAD DE CARACAS
Y, ¿ adivinan ? Apenas comenzamos a trabajar en este sector, la EDC evaluó también de manera muy
positiva nuestra nueva línea de equipos y el desenvolvimiento de nuestra empresa nacional de
tecnología, y comenzó a su vez un proceso de sustitución de unidades viejas (HONEYWEL y
CONITEL) por las RTU nuestras, así como la instalación y aprovisionamiento de las mismas en sus
subestaciones nuevas, o en otras que aún estaban en construcción.
Todo esto parecía una especie de “efecto dominó”, en reversa, que contraviniendo asombrosamente la segunda
ley de la termodinámica, iba levantando ante nosotros peldaños por los que pudimos ascender…

ESTRATEGIA TECNOLÓGICA: NUESTRA FORTALEZA


Para la ilustración y guía de las nuevas huestes de ingenieros electrónicos, próximos a incursionar
en el campo profesional, quiero recalcar tres o cuatro grandes líneas estratégicas, gananciosas, que
establecí en el área tecnológica y que, desafiando el paso del tiempo, catapultaron con éxito durante
veinte (20) años las empresas para las que trabajé, mías o ajenas, desde 1983 hasta 2003. No quiero
decir con esto que todos tengan que tomar mi camino; simplemente pretendo mostrar lo que yo
hice, por qué y cómo, y los resultados tan positivos que alcancé. Es prerrogativa de cada cual
recorrer sus propios senderos…

1) INTEGRADORES DE SISTEMAS
Nuestras compañías debían ser “Integradoras de Sistemas”, con mayúsculas, entendiéndose por
ello que no reinventarían la rueda en la solución de problemas. Consideremos un DFR, que tiene,
entre otras, una unidad que procesa datos, toma decisiones y ejecuta acciones como comunicarse
con su estación maestra… Esto es, a las claras, la función rutinaria de un PC, y no íbamos a
diseñarlo sino a ubicar en el mercado uno apropiado, con características industriales (ProLog los
primeros 12 años, CompuLab después). Y como para la comunicación se necesitan MODEMs,
compraríamos los de MOTOROLA...

Es decir, que nuestro papel como Integradores de Sistemas sería el de definir el problema a nivel
conceptual, y resolverlo empleando un arreglo de unidades o equipos que, fundamentalmente, no
construiríamos sino que adquiriríamos de terceros, y los reuniríamos en bloques para conformar
nuestra solución. Era como proyectar con “chips”, analógicos o digitales, que encapsulan una gran
cantidad de tecnología que el ingeniero no diseña, y que a veces ni siquiera entiende; pero haciendo el
diseño a un nivel conceptual más elevado aún, en donde los elementos no eran circuitos
integrados sino subsistemas completos. A esta clase de empresas se las llama en ocasiones
“Original Equipment Manufacturers”, OEM. Nuestro hardware autóctono se redujo así a tarjetas
de interconexión, con conectores de un tipo en las entradas y otros, apropiados, a la salida; tarjetas

3
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

para alojar las fuentes de alimentación; circuitos impresos con filtros simples en los puntos de
entrada, analógicos y digitales, “back-planes” para interconectar racks, gabinetes para los equipos,
unidades de interposición, cableado interno… El software sí fue más abundante aunque, como ya
dije, el código que podía comprarse, o incorporarse gratuitamente, no se reescribía, con lo que gran
parte de nuestra programación también consistió en “interconexión” de módulos de software,
rutinas de calibración, interfaces entre la máquina y los humanos… y ya pueden ir haciéndose una
idea precisa de nuestra operación.

Logré que nuestra labor en los proyectos se desarrollara a un nivel conceptualmente superior al
convencional; fui uno de los pioneros en el mundo en considerar el PC como un “componente”
más, para incorporar en dispositivos de hardware (cfr. “Computers as Components”, Wayne Wolf,
Elsevier 2005) pero… lograr la comprensión de quienes me rodearon no siempre fue posible, ¡ y ni
siquiera lo es aún en la actualidad !

No nos equivoquemos: La concepción del sistema y el desarrollo de las partes no estándar, en


hardware y software, resultan siempre de considerable dificultad, porque también la complejidad
de los proyectos encarados es mayor, si los comparamos con los que empresas de similar perfil
elaboran… desde cero, desarrollando precisamente ellas mismas cosas tales como conversores,
fuentes, procesadores… o sistemas operativos ad-hoc y módulos de acceso a Internet, en lo
atinente al software.

Es importante resaltar que esta aproximación de integradores produjo, siempre, equipos y sistemas de mucha
complejidad, de grandes prestaciones y alto vuelo, permanentemente en el eje de avanzada tecnológica, que
compitieron sin ayuda oficial (dumping) con los desarrollados por empresas mundiales, de gran prestigio y
músculo financiero… y lo hicimos porque nunca reinventamos la rueda.

Da pesar que haya aún profesionales, y sobre todo docentes, quienes enseñan que es al revés
como debería trabajarse. Suelen ser aquellos que nunca fueron empresarios.

Esta postura fue apropiada, primero, por nuestra dimensión económica, de empresa y de país: Ni
nuestro entorno venezolano, ni siquiera el latinoamericano, permitían realizar diseños de bajo
nivel, viables solo cuando se comercializan grandes volúmenes, a los que no teníamos acceso en la
región, y que son la única manera de recuperar los costos de desarrollo y lograr precios
competitivos. ¡ Nadie iba a adquirir nuestros equipos, por buenos que fueran, si estos no resultaban
más asequibles que los de la competencia !

Además, la integración de sistemas presentaba varias ventajas más, siendo la del manejo de la
obsolescencia tecnológica una de las de mayor importancia. Con esto quiero decir, por ejemplo,
que cuando comenzamos seleccionando nuestro primer PC industrial ProLog, este se basaba en
un Intel 8088. Pero transcurrió el tiempo en trámites administrativos y, cuando realmente lo
recibimos en nuestras oficinas, ya el proveedor empleaba un 80286. Para los siguientes proyectos
los computadores se basaban en 80386, 80486, Pentium… y así sucesivamente, sin que nosotros
tuviéramos que lidiar con la angustia de cambiar presupuestos o cotizaciones (era común desde los
años 70 que se aumentara el poder del procesador pero se sostuvieran los precios), ni andar en una debacle
de rediseños y cambios significativos e inconvenientes en nuestra línea de producción, o en la

4
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

procura de componentes, para ajustarnos al bamboleante cambio tecnológico que, en electrónica, es


vertiginoso. Y lo mismo que con el PC, ocurría con los MODEMs, los conversores, las interfaces,
las fuentes de alimentación… ¡ con todo !

Pudimos así ofrecer equipos con funcionalidades modernas (recordemos que estamos hablando de 1986
hasta 1995), tales como sincronización vía GPS, MODEMs de fibra óptica, fuentes de poder
eficientísimas y de versatilidad asombrosa (entrada universal, tanto AC como DC y voltajes desde 24
hasta 240V, frecuencias de operación en AC: 60 y 50Hz), discos de almacenamiento enorme,
memorias al gusto, radios, celulares, comunicación empleando el tendido eléctrico (Spread
Spectrum) ¡y mucho más! Y el software, que comenzó en $60 cada aplicación, después resultó
gratis: Linux, stacks TCP/IP, rutinas matemáticas… todo al alcance de la mano.

En esa época, ni nuestros competidores en el país ni los foráneos eran integradores; al revés:
diseñaban todo, y nuestros rivales locales no recuperaban los costos de ingeniería y desarrollo (sin
que, sin embargo, ese fuera, tampoco, el peor de sus problemas…)

2) ARQUITECTURA ABIERTA Y ESTÁNDAR


Como decidimos usar el PC como componente de diseño para el corazón del hardware de
nuestros equipos, las interfaces y periféricos eran estándar, y el hecho de que sus especificaciones
fueran abiertas y de dominio público trajo consigo: precios competitivos, facilidad de consecución,
variedad a la hora de la selección (existencia de fuentes alternas de suministro o “3rd. parties”);
universidades que proveían profesionales bien entrenados, con conocimientos en el área… y
gozamos de las ventajas, hoy por todos conocidas, derivadas de trabajar con dispositivos estándar, de
arquitectura abierta y amplia divulgación.
Para el segmento del software trazamos dos (2) lineamientos que resultaron igualmente exitosos:
El lenguaje de programación sería fundamentalmente el “C”, y nuestros equipos se basarían en el
sistema operativo DOS, de amplia utilización en los PC de aquella época. Estas guías hicieron que
nuestros proyectos pudieran codificarse programando en el computador personal de cada quien,
sin apelar a grandes y costosos sistemas de desarrollo especializados (SDK). La estandarización en
el área de software hizo también que fuera sencillo y económico comprar módulos o subrutinas. Si
un equipo en particular tenía que manejar una impresora, adquiríamos un “Spooler” como PrintQ
por US$60 para atender simultáneamente el proceso y la impresión. Las rutinas de comunicación
de datos vía RS232 eran estándar, costaban US$60 (Blaise Computing) y permitían la ejecución
concomitante de la aplicación y la transmisión de información. Si necesitábamos procesamiento de
señales tipo FFT, se conseguían rutinas para el PC-DOS, escritas en “C”, con solo tronar el dedo…
Alrededor de 1983 estas decisiones no parecían para nada obvias, y de hecho nuestros
competidores nacionales y extranjeros trabajaban ¡reinventando la rueda una y otra vez! Sus
procesadores, por ejemplo, eran diseñados por ellos; sus periféricos, también; los sistemas
operativos eran del estilo del i RMX86, costosos y desconocidos por los profesionales locales. El
lenguaje de programación era PL/M y, en algunos casos, Assembler, Basic o Pascal, para los que no
existía la plétora de paquetes y bibliotecas que nosotros conseguimos, siempre, para el “C” y el PC-
DOS, ni a tan excelentes precios. Anoto, a modo de ilustración, que nuestras empresas siempre
facturaron bien la mano de obra, entre US$25 y US$100 o más, por hora de ingeniero, dependiendo

5
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

del tipo de actividad y del perfil del profesional, lo que pone a las claras de manifiesto que era
preferible adquirir rutinas o paquetes como los mencionados, y otros más, que desarrollarlos
nosotros mismos, no por falta de capacidad, ni mucho menos, sino por un criterio económico: los
US$60 del precio de compra solo equivalían como a una hora de trabajo de uno de nuestros
profesionales. Eso es fruto de la Escala de Mercado y de la Dimensión Económica de los desarrollos.
Si nuestra competencia necesitaba una unidad de comunicaciones seriales, por mencionar dos
casos reales, que aún recuerdo, era para ellos todo un señor proyecto, de hardware y de software;
lo mismo si querían añadir una interfaz local de video al equipo. Para nosotros ¡todo esto era
estándar, de fácil consecución, excelente calidad, probado, depurado, actualizado y económico!

En esa época, apostamos a la estandarización ¡ y ganamos !

3) INGENIERÍA REVERSA DE PROTOCOLOS


Aprendimos desde muy temprano que para poder vender nuestros equipos tendríamos que
insertarlos en sistemas preexistentes pues los SCADA, por sus precios y complejidad, los
suministraban normalmente compañías muy importantes a nivel mundial, como TRW, FERRANTI
Int'l Controls, HARRIS, ABB, SIEMENS y WESTINGHOUSE, por lo que teníamos que dominar el
proceso de comunicación, de tal manera que sus sistemas aceptaran nuestros equipos y se
entendieran con ellos como si fueran los suyos propios. Esto implicaba que debíamos, entre otras
cosas, hablar sus mismos “protocolos” de comunicaciones que, en general, no los hacían públicos,
ni mucho menos, sino que más bien los mantenían con bastantes reservas y confidencialidad.

Ocultar su lenguaje de comunicaciones ayudaba a las grandes compañías a ahuyentar la competencia.

Una de nuestras fortalezas fue entender cuanto protocolo existió. De esa manera pudimos
conectarnos con sistemas ASEA, SIEMENS (SINAUT), HONEYWELL (7024), CONITEL (2020), MODBUS
(RealFlex), HARRIS (DNP 3.0), WESTINGHOUSE (WDPF II), TCP/IP… y una miríada de dialectos que,
al asimilarlos, posibilitaron –muy a pesar de la competencia– nuestra inserción en sus grandes y
tan celosamente resguardados sistemas. Entre nuestras muchas primicias a nivel mundial
tuvimos equipos con más de un protocolo simultáneamente, en casos en donde ¡nuestros
competidores habrían tenido que colocar 2 o 3 RTU físicas!

4) PRESENCIA LOCAL
Una gran diferencia que establecimos con nuestros competidores foráneos radicó en que en este
segmento de actividades teníamos una presencia local contundente, y permanente era la atención
que brindábamos a los clientes. No nos limitábamos a la oficina convencional, con un gerente y
una secretaria, y una llamada nocturna a Europa solicitando órdenes. Nuestra respuesta siempre
fue perentoria. A nuestros competidores se les aplicó, como máxima: “De lejos, hasta los muy
grandes parecen pequeños…”, y nosotros estábamos “…tan cercanos, que parecíamos grandes…”

6
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

ASCENSO Y CAÍDA
Fuimos tan exitosos con estas líneas de planificación estratégica, que colocamos en la década de los 90,
una de nuestras RTU en cada una de las subestaciones eléctricas de la EDC, tanto en el
sector de Transmisión como en el de Distribución eléctrica, y también en el SCADA de Generación
(Tacoa, la planta principal), así como otros dispositivos pequeños (como UPAs: Unidades
Procesadoras de Analógicos), aguas abajo de las RTU de Distribución. Esta situación, al lado de
resultar más que halagadora para nuestros egos, y económicamente muy conveniente para las
finanzas de nuestras compañías, se convirtió también en nuestra mayor preocupación, por la
inminente ¡saturación del mercado circundante!

Comenzamos entonces por explorar otras empresas locales, como EDELCA (en Caracas y Puerto
Ordaz), ENELVEN (Maracaibo) y GENEVAP (Punto Fijo), y otros equipos de nuestro diseño se
sumaron así a los Registradores de Fallas DFR y a las RTU, como fueron los Secuenciadores de
Eventos, SOE, los Power Swing System Recorders, PSSR, y muchos más.

Buscamos también atender otros países; ganamos licitaciones públicas en Costa Rica (Instituto
Costarricense de Electricidad, ICE) y en Ecuador (Instituto Ecuatoriano de Electrificación, INECEL). En
Colombia se hizo realidad la máxima aquella de que “nadie es profeta en su tierra”.

DISTRIBUCIÓN DE SISTEMAS NUESTROS, INSTALADOS HACIA 2003

- LA ELECTRICIDAD DE CARACAS:
 RTU Generación, Planta Tacoa (100%)  nano RTU (2%)
 RTU de Distribución (100%)  SOE (100%, estimado)
 RTU de Transmisión (100%)  DFR (100%, estimado)
 micro RTU (20%)  SCADA (Tacoa)

- PDVSA (MARAVEN):
 RTU para S/E Eléctricas (40%)  micro RTU para S/E H (19%)
 micro RTU para E/Flujo (26%)

- ENELVEN, SISTEMA DE SUPERVISIÓN DE PLANTA RAMÓN LAGUNA


 RTU de generación (30%)  micro RTU (100%)

- PDVSA (CORPOVEN-EL PALITO):


 Supervisión de la S/E de la Refinería (100%)

- GENEVAP:
 Sistema de Supervisión de Plantas y Subestaciones; equipos PSSR, SOE y DFR (100%)

- ENELBAR:
 Sistema Registrador de Energía (DFR y Unidad Maestra) (100%)

7
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

- EDELCA:
 Supervisión S/E Guayana B; todas las  SOE para el sistema de 400 kV
RTU  DFR para el sistema de 800 Kv

SISTEMAS NUESTROS, INSTALADOS EN OTROS PAÍSES_

- INSTITUTO COSTARRICENSE DE - INSTITUTO ECUATORIANO DE


ENERGÍA (ICE): ELECTRIFICACIÓN (INECEL):
 RTU (30%)  PSSR (25%)

Finalmente, hacia 1999, la perspectiva más atractiva para nuestro grupo de empresas estaba en la
industria petrolera venezolana (MARAVEN, filial de PDVSA), donde incursionamos suministrando
RTUs para dos planes “piloto” de extraordinaria importancia y de mucha proyección pues se abría
la posibilidad de automatizar alrededor de 8,000 pozos… Un pozo, una remota…
Pero… hubo de repente un cambio drástico en la política petrolera venezolana cuando, para
impulsar el aumento del precio del combustible se ordenó la reducción de la producción, y ya no
se automatizarían los pozos que habíamos proyectado, por la elemental razón de que no iban a
estar operativos. Así, al menos, nos lo hizo saber PDVSA, que nos recomendó regresar en el 2004.
Como las calamidades nunca vienen solas, a esta decisión se le sumó la reducción general de la
inversión en el área eléctrica de la nación: la de los empresarios privados, por el temor y la
incertidumbre frente al futuro, y la del sector público por la redistribución de recursos para
aplicarlos en áreas sociales. Nos vimos obligados a mirar, por primera vez en 20 años, al otro lado
de la línea fronteriza de nuestro cliente natural, al que siempre habíamos atendido (que era el
operador, productor, transmisor y distribuidor de electricidad…) y nos focalizamos en un nuevo
prospecto: EL USUARIO DEL SERVICIO ELÉCTRICO.

LA LEY Y EL ORDEN
Hacia finales del tercer trimestre del 99 se publicó un decreto-Ley del Servicio Eléctrico, para
garantizar el suministro de electricidad al menor costo posible y con la calidad requerida por los
usuarios; promover la competencia; regular situaciones de monopolio y fomentar la participación
privada en el ejercicio de las actividades que constituyen el servicio eléctrico.
Dichas actividades debían ser ejercidas por distintas compañías. A diferencia de las empresas de
servicio de aquel entonces, que podían encarar todas las actividades, se estableció que una misma
firma no realizaría dos o más de las actividades de Generación, Transmisión, Gestión del Sistema Eléctrico
Nacional, y Distribución. ¡Drástico y radical cambio! Además:
Los usuarios tendrían derecho a compensación económica de parte de la empresa eléctrica,
debido a deficiencias en la calidad del servicio prestado.
El mencionado decreto necesitaba leyes reglamentarias, que no estuvieron listas a tiempo para
servirnos de ayuda en la toma de decisiones respecto a incursionar en esta área, pero las

8
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

legislaciones latinoamericanas equivalentes, y otros modelos, norteamericanos y europeos, incluían


los siguientes parámetros para medir la Calidad del Servicio prestado:

 Energía no servida  Otras deformaciones del Voltaje


 Flicker suministrado (SAG, SWELL, etc.)
 Contenido de armónicos

La ley ordenaba, igualmente, crear la COMISIÓN NACIONAL DE ENERGÍA ELÉCTRICA, regulatoria, y


el CENTRO NACIONAL DE GESTIÓN para operación del Sistema, en un plazo de dos (2) años.

¡NADA DE ESTO SUCEDIÓ! Hoy, a doce años de promulgada, aún se encuentra en vacatio legis; no se
crearon los entes requeridos, y más bien han surgido múltiples problemas, muy serios, en el sector
eléctrico, estatizado casi por completo. Eso lo sabemos ahora; pero en 1999 fundamos
ElectriAhorro como respuesta proactiva para lograr ser los primeros en aprovechar la nueva
realidad, que se crearía en el sector eléctrico debido a esta ley, tan moderna y tan de avanzada…, y
gracias a los reglamentos… que iban a publicarse, y a los institutos y organismos… que estarían
por fundarse.

CRASO ERROR.

 SÍNTESIS DEL PROYECTO ELECTRIAHORRO


Una consideración que puede resultar de interés a los curiosos, es cómo obtener una cifra, calculada
grosso modo, de lo gastado en este diseño. La aproximación es la siguiente: En la compañía trabajaron (al
menos) 10 personas (ingenieros, administradores) para este proyecto, con sueldos mensuales promedio
de $2,000 c/u (bolívares dolarizados al cambio de la época), cargas sociales estimadas en el 50%
(vacaciones, prestaciones, utilidades, seguros y otros beneficios, bonos y demás; la empresa multiplica
por 1.5 lo que el empleado percibe mensualmente, y esa cifra corresponde a lo que se tiene que erogar
en algún momento), durante dos años y medio (30 meses, desde septiembre de 1999). Entonces: 2,000 *
1.5 * 10 * 30 son $900,000 aproximadamente. No se suman en este análisis rasante, otros costos
directos y obvios, como el de los componentes empleados, porque su valor resulta más o menos
marginal al compararlo con la cifra erogada en mano de obra.
Un proyecto tiene muchas facetas: técnicas, económicas, de impacto, de proyección, del hardware,
del software, las comunicaciones, la visión, el manejo del personal, los clientes, la comercialización,
la producción, el entorno, la viabilidad, sostenibilidad… Este resumen lo presento en forma de
ítems numerados, para facilitar su empleo como lista de verificación (check list) que creo vale la
pena repasar y aplicar para otros proyectos similares, y no tan similares…

1. Mi primera conclusión será que el método que diseñé, implementé y que fue exitoso durante la
vida del proyecto comercial, puede aplicarse aún hoy, a sistemas que requieren obtener
valiosa información del campo y transmitirla para servirla, y que abarca multitud de
clientes, o puntos de lectura. Hoy veo grupos de trabajo realizando actividades como las
descritas, que simplemente envían un SMS o un datagrama, vía celular, a un PC, y con eso
creen que ya pueden dar por satisfechas sus necesidades.

9
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

¡NO ES CIERTO! La información es preciosa. La multitud de cosas que pueden salir mal
requieren de una formalización en las especificaciones de los proyectos, que incluya garantizar
que nunca, o muy rara vez, puedan perderse los datos.
2. Las ventajas del “desacople” mayúsculo que un servidor de correo puede proporcionar al
colocarlo en el medio, sobre todo si éste corresponde a un proveedor comercial de servicios de
Internet, la facilidad de redistribución de la información a un número indeterminado de
localidades, para su respaldo, así como para ulteriores manipulaciones, son inmensas en relación
a un sistema súper acoplado, en el que el punto de lectura es, a su vez, servidor de algún
protocolo de Internet, como el de páginas web, con un modus operandi en el que es la estación
de trabajo la que tiene que acceder al punto de lectura, quien “sirve” la información mediante el
protocolo de conexión HTTP y el HTML para acceso a los datos. Esa configuración requiere
mayor acople entre los extremos, lo que resulta en mucha menor flexibilidad.
Sí; es verdad que en ocasiones, cuando hay que acceder, por ejemplo, a un dispositivo local
como un pequeño enrutador para la red del hogar, resulta cómodo que este equipo
implemente un sistema de servidor de páginas web, que permita con mucha sencillez acceder a
los diversos parámetros de configuración. Pero no es ese el caso de sistemas de adquisición de
datos como el de ElectriAhorro.
Desde luego, los tiempos cambian, y lo que fue bueno en 1999 tiene que ser adecuado a la
realidad del 2011. Ahora, a lo mejor, habría que analizar el Twitter, o los SMS. Pero no hay
que menospreciar esta gran facilidad de desacople entre los extremos.
3. Mi siguiente conclusión va en forma de llamado de atención a quienes todo lo quieren
diseñar. Mi grupo de trabajo, que había realizado las hazañas que relaté en la introducción, a
nivel tecnológico, aún así no hubiera podido implementar dentro de un solo equipo las dos
funcionalidades, de medida y de comunicación. Las flexibilidades que luego resultaron, como
la interfaz con UPAs, Virtual-IaMs, o conexión con cualquier medidor con un puerto de 232
o 485 fueron muy reconfortantes y le dan al sistema un grado de adaptabilidad muy grande.
Desde luego, hoy, yo ni siquiera hubiera hecho el IaM. Las razones que nos llevaron a
incursionar en el campo de las RTU (que podíamos vender por la mitad de precio un equipo
para el que no existían alternativas en el mundo, competir con los suplidores de SCADA en
sus propios nichos, y ganar mucho dinero), no resultaron válidas con el IaM. Aquí los
chinos y canadienses, y los españoles y alemanes, y ahora Google con el software (gratis), son
imbatibles, económicamente hablando, y no se justifica la inversión. Por las mismas razones
que no hay que hacer PCs en Venezuela, tampoco hay que hacer IaMs. La solución de los
problemas, el conocimiento del mercado, la presencia, la solvencia técnica, el “know-how” no
precisan que el equipo sea hecho en casa, máxime cuando no tenemos la bendita dimensión
económica que permita economías de escala. Hoy por hoy la situación mundial no nos permite
competir; de nuevo: no por falta de capacidad técnica, sino por el entorno económico. Se
necesitan volúmenes extraordinariamente grandes, que nosotros no podemos cubrir, para
desarrollar equipos con la cantidad de alternativas que en realidad se requieren.

10
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

4. Pero esto es una digresión; el sistema de comunicaciones que definí mediante el AS!MP: A
Simple !Mailer Protocol., tuvo relevancia y aún hoy la tiene, por la forma de encarar el
intercambio de información. Este proyecto cubrió aspectos bien importantes que pueden
analizarse y evaluarse, en su aplicación a otras muchas situaciones, sobre todo en el entorno
donde nos movemos; esto son:
5. Estrategia Tecnológica, fundamentada en la idea de no reinventar la rueda, lo que me
impulsó a declarar nuestro enfoque como el de:
6. Integradores de Sistemas, empleando equipos y dispositivos suplidos por otros, y de:
7. Arquitectura Abierta y Estándar, el empeño en incluir protocolos comerciales, cada vez más
públicos (como el Modbus), pero apelando sin duda a la Ingeniería Reversa de Protocolos
para aquellos casos en que se usa el mecanismo de comunicación por medios ocultos,
cerrados, como un elemento para acordonar el mercado.
8. El uso, desde luego, de PCs, de altísimas prestaciones y precios inimaginables, como el Credit
Card PC, sin olvidar nunca la búsqueda y aseguramiento de Garantías de Manufactura y
Disponibilidad, para no poner a la empresa en riesgos innecesarios.
9. Del lado del SERVIDOR, haber empleado Linux (Debian) con todos sus espectaculares
paquetes de acceso libre, como el servidor de base de datos (Postgres), los sistemas de manejo
de correos (SendMail), la miríada de programas de envío y recepción de emails, como el mutt
o el mail. Los interpretadores de scripts, como el Perl, todo esto en Servidores que son
máquinas virtualizadas, cada vez más económicas.
10. Un aspecto muy importante es que todo mi sistema de la parte del Server, puede
ejecutarse desde cualquier PC conectado a Internet, como el computador personal de mi
casa de habitación. Esto representa una flexibilidad inimaginable. Puedo subir correos desde
cualquier lugar, aquellos que he recolectado de manera manual, por ejemplo. Este tipo de
aproximación es necesario considerarla cada vez que tenemos un proyecto. Si todo depende de
un equipo servidor, y hay que tener acceso (remoto) a él para hacer cualquier cosa, la solución
no es tan elegante ni flexible como la que diseñé, y que aquí reseñé.
11. Haber empleado el mismo hardware del IaM, trabajando como !Mailer, para poder
cumplir los tiempos de desarrollo y garantizar la funcionalidad del sistema de transmisión de
información, fue también una decisión oportuna.
12. Haber pensado desde el principio en todas las Modalidades de Operación que permitieron
ajustar el sistema a una amplia variedad de circunstancias, como el uso de modems CDPD,
!LanMailers, !SMailers, Virtual IaMs (UPAs), e incluso la posibilidad de instalar otros
equipos, como así se hizo, que nunca tuvieron acceso al correo electrónico o al Internet.
13. La conceptualización del AS!MP como un “Gateway” y su materialización en el Sistema
!Mailer, fue crucial para el proyecto. Como ya dije, muchas voces abogaban por soluciones
copiadas de otras latitudes, en lugares donde la interconexión a Internet puede ser mucho más
sencilla y económica que en nuestro medio, y en donde implementar servidores de páginas

11
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

web en los puntos de medición podría resultar apropiado. (Se analizó el caso de las máquinas
dispensadoras de refrescos en USA)
14. La definición estricta de las Secuencias de Mensajes en el protocolo de comunicaciones:
Determinación del mecanismo de aceptación o rechazo: ACK0, ACK1, NACK, y todo el
estudio de los posibles mecanismos de falla, específicos, como muchos o ningún ACK; el
cifrado de la información para proteger el sistema de intrusos, locales o externos.
15. El sistema, concebido para recomenzar en cualquier parte del proceso y acomodarse
para empezar de nuevo, o para continuar, en caso de que esto sea posible.
16. Haber incluido tantas Clases de Mensajes, como  los generados en forma Manual,  los
automáticos y regulares,  los de reportes puntuales (Snapshots),  los de registros de fallas, y
que algunos de ellos, como por ejemplo los registros de fallas, además de llegar al Server, iban
a casillas de correo alternativas para procesamiento independiente.
17. Agregar el concepto de Near Real Time, NRT, para aquellas instalaciones que tienen su
propio SuperMailer dedicado, que puede acortar los intervalos de comunicación, con lo cual
pueden cerrarse o abrirse interruptores, o tomarse otras acciones de control, dentro del tiempo
de barrido, que puede ser, por ejemplo, de uno o diez minutos, fue un paso en el camino
correcto. No se vio muy bien cuando los tiempos de comunicación eran de una vez al día,
pero la tecnología rápidamente cambió eso, con los Modem CDPD en aquel momento. No es
un sistema de control de Real Time, pero tampoco tiene las complejidades de aquellos, ni sus
costos. Ni las necesidades previstas tenían tampoco esos requisitos, según analizamos.
18. Programar los equipos remotos, tanto IaM como !Mailer, empleando el mismo
mecanismo de comunicación, fue una de las cosas que ahora queda claro que había que haber
pensado. Si usted tiene una instalación de equipos, que pueden crecer a 1,000 por año, no va a
querer reprogramarlos trayéndolos a la oficina, porque eso es muy costoso. Y ya todos
sabemos, aunque lo deploremos, que siempre aparecen mejoras qué hacer, y errores qué
corregir…
19. En otras áreas de atención, haber controlado el Modem (en todas sus modalidades)
encendiéndolo y apagándolo como si fuera un equipo de escritorio (vía relés heredados de
IaM) fue muy productivo porque en el transcurso de tantos años, ¿cuántas veces no vi tales
equipos, confundidos, como en un limbo, esperando una misericordiosa acción manual?
20. La implementación de todo el concepto para el Sistema Operativo, DOS, a pesar de las
voces que recomendaban  no emplear ningún sistema operativo (desde siempre hubo
opositores a la idea de que una RTU necesitara un sistema operativo de soporte), o aquellas
que indicaban el  uso de otros, como el eCOS. Siempre habrá OTRO sistema mejor que el
actual, pero yo aprendí a vivir con las Versiones. Desde que Microsoft presentó su DOS 1.1,
que casi no hacía nada, y la manera como fue produciendo, y cobrando, las versiones 1.2, 2.0,
3.0, 3.1, 5.0, etc… Algo hay que aprender.
21. Lo mismo ocurrió con mi decisión del lenguaje “C”, flanqueada entre los que por un lado
querían Assembler y los que por el otro propugnaban por el C++.

12
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

22. Enfrentarme con los protocolos de Internet, para enviar correos y para leerlos, resultó muy
sencillo… porque son fáciles: cada protocolo tiene, además de formatos que cumplir,
comandos que permiten acceder, listar, leer, borrar, enviar… correos. Todo lo pude simular a
mano antes de programarlo, para asegurarme de que las secuencias eran las correctas. Qué
simplicidad… Luego, trasladar esa actividad manual a “C” ocurrió en forma inmediata.
Ciertamente hacer los Programas “BAT” del !Mailer no fue una tarea sencilla, porque el
sistema de archivos BATCH de DOS era anacrónico y sobresimplificado.

23. Generar LOGS PARA TODO, y enviarlos en correos electrónicos para su análisis, realmente facilitó
la tarea cuando el sistema creció y comenzaron los problemas. Que Telcel cambió sus DNS
names, que ya nos se empleó más el protocolo PAP, sino que lo cambiaron sin aviso ni protesto
por el más seguro, CHAP. Que en la oficina desconectaron el teléfono. Que siempre deja de
trabajar a la misma hora, y corresponde al momento en que el guardia de la caseta de entrada
desenchufa el !Mailer para conectar de noche su pequeño televisor y ver la telenovela. La
cantidad de inconvenientes, que se suman todos en contra de la operación del sistema, que no
son culpa del mismo pero que el cliente no entiende, y que resolverlos requieren
INFORMACIÓN… Nunca deje de reportar TODO en los LOGS. Así se enterará de que su sistema
se considera, a sí mismo, instalado en una ¡zona sujeta a horario de Daylight Saving Time!

24. Finalmente, del lado del SERVER hice también “tools” que ayudaron en la presentación de los
resultados, como RFBREAK.AWK, XTIME.AWK, MAX_T.SH. Pero, desde luego, el que se llevó las
palmas en utilidad fue el HAMPEL FILTER “HF.PL”. En otras oportunidades lo he usado para
filtrar datos, con resultados muy alentadores. La programación la hice en Perl porque corre
tanto en Unix (Linux) como en Windows, pero el corazón del programa es tan sencillo que
puede trasladarse con facilidad a Excel, MatLab y similares.
Espero que el conjunto de 24 puntos que acabo de enumerar, empleados en el diseño del sistema aquí
reseñado, y que fue probado exitosamente en el campo durante varios años, sirva de referencia a la
hora de realizar proyectos de Telecomunicaciones, en donde remotos robots informáticos envían
información a robots Servidores, de manera confiable y eficiente, empleando un mecanismo que
siempre se pensó para comunicación entre personas: “Machine to Machine eMails”.

13
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

 CONCLUSIÓN
El diseño del Sistema ElectriAhorro es excelente desde el punto de vista de interpretar necesidades
y ofrecer soluciones muy avanzadas, y se armó con computadores, MODEMs, fuentes, cajas,
sistemas operativos, protocolos… ¡como si fuera un Lego! Incluyó, como herencia, la tecnología de
nuestros proyectos predecesores.

El párrafo anterior compendia, en cierta medida, mi visión de la “Ingeniería confinada a su Circunstancia”.


Esta concepción no siempre ha sido aceptada por algunos de mis jefes, socios; colegas, académicos o industriales, que
a veces dirigen sus esfuerzos personales y económicos al bajo nivel: El diseño de una rutina de comunicaciones aquí,
el de una tarjeta de red por allá, y casi todos elaboran sus propios computadores… todo esto, justo donde la
investigación de la competencia, su músculo financiero y su dimensión económica, nos doblegan con facilidad. Mis
equipos fueron reconocidos durante 20 años por una calidad inherente, estructural, ¿otorgada por? ProLog y
CompuLab que hicieron los mejores PCs industriales; Motorola que diseñó, construyó y probó los MODEM; Analog
Devices y sus imbatibles ADC… a Lambda nadie le ganó jamás concibiendo FUENTES de alimentación… y mis
componentes fueron probados en miles, en millones de sitios… ¡por otros! y avanzaron de la mano de la tecnología
pero… no lo hicieron a mi expensas.

Para realizar mis proyectos a más bajo nivel se hubiera necesitado el tamaño de las grandes empresas, y aún así, eso
no se hubiera justificado : Aquellas, se las vieron a gatas al competir con nosotros porque, además de lo dicho
hasta aquí, siempre nuestros precios fueron mejores. ¡Claro, teníamos la Dimensión Económica a nuestro favor!

Cómo sería… que alguna vez mi competencia adquirió nuestros DFRs


¡y los vendió a Edelca en lugar de los suyos propios !

14
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

EPÍLOGO

Como un ejemplo real de la Ingeniería Electrónica Venezolana, finalizo enumerando los más
importantes de nuestros demás productos, casi todos desarrollados para la industria eléctrica:
1. Registrador Digital de Fallas, DFR: Se conectan a los PT y CT (Potencial and Current
Transformers); se comunican vía Modem con una Maestra. Detectan "fallas" por extra-límite:
depresiones en V o subidas en I. Lecturas: 1200 y 5000 veces por segundo a todos los canales. Se
guardan en “buffers” de 2 ó más ciclos. Al momento de la falla se tiene así el estado de las señales
de "antes" de la falla ("prefalla"); se congela esa información, se añade la falla, hasta 600 ciclos. Al
final se agregan 1 ó 2 ciclos de "postfalla". Una falla despejada normalmente por las protecciones
lleva 12 ciclos. La Maestra recolecta automáticamente los datos, conforma "Registros de Fallas",
las visualiza, imprime (hoja continua, o láser, papel carta), almacena, compara, manipula, hasta
256 DFRs. Típico 32 canales analógicos/32 digitales (hasta 64/64). Van en racks de 19 pulgadas de
ancho por 22 cm. de alto; profundidad estándar. Los hay portátiles (maletín metálico).
2. Secuenciador de Eventos, SOE. Como el DFR, pero lee puntos digitales asociados a las
Protecciones. Cuando sucede una secuencia de aperturas y cierres, lee cada señal y si ha
cambiado le añade la identificación y la hora del cambio con resolución de 1 ms. Así la
Maestra puede ordenar cronológicamente la serie de eventos, permitiendo determinar qué
interruptor operó antes o después que otro, y con qué diferencia en tiempo. Comunicación vía
Modem con la Estación Maestra. Hasta 1024 puntos. Van en racks como los DFR.
3. Maestra. Comunicación vía Modem, radio, microondas. Localizan una falla con precisión,
señalándola entre dos torres. Calculan depresiones, picos, tiempo entre eventos.
4. Unidad Terminal Remota, RTU. Competimos y ganamos licitaciones contra Asea (Enelven),
Ferranti (Opsis; EDC Transmisión), Honeywell (Edelca, EDC Distribución), Conitel (EDC
Distribución), Brown Bovery; Siemens (Instituto Costarricense de Electricidad, ICE).
También con Harris y otras más. Fuimos expertos en emulación de protocolos. Eliminamos
los Transductores Externos (leemos V e I, y producimos RMS). Extras: medición de energía,
secuenciamento de eventos, control local, panel mímico (puerta del gabinete), lecturas
especiales (termocuplas, RTD). Tamaños: Grandes, normales, micro-remotas, nano-remotas; de
poste, de tanquilla, con comunicación vía fibra óptica, Spreads Spectrum… Unas RTUs pueden
trabajar como Maestras para otras, configurando así Redes Jerárquicas.
5. Test Set. Unidades portátiles multiprotocolo para probar RTUs, propias o ajenas.
6. Registrador Digital de Carga (Portátil). Dpto. de Planificación: pronóstico del aumento de la
demanda; perfiles (para tarificación). Calcula y almacena: Potencia Activa, Reactiva, Aparente y
Factor de Potencia.
7. Registrador de Energía. Calcula potencia activa, reactiva; energía monofásica, trifásica. Emplea
líneas telefónicas discadas.
8. System Power Monitor. Calcula P, Q, S y frecuencia, 20 veces por segundo. Unidad Maestra
(visualización Fasorial).
9. Scadas. Modificamos y aumentamos el producto comercial Realflex (VSCADA).

15
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

En la actualidad incursiono en el área de “Telefonía Celular aplicada a la Automatización”,


programando la plataforma Android de Google en su materialización como Motodev de Motorola.
El campo de aplicaciones es inconmensurable. Los invito a todos a estudiarlo. Se soporta sobre
Linux, Java, y SDKs poderosísimos y de libre acceso, todo gratuito, con mucha información, libros
y grupos de gente trabajando, que comparten sus experiencias…

Presiento que los Smart Phones son hoy, a los proyectos,


lo que fueron los PCs en la etapa anterior.

Les deseo a mis alumnos, cuarenta años de exitoso desarrollo profesional,


tan reconfortantes y excitantes como los que yo tuve la oportunidad de vivir.

Ing. Luis G. Uribe C.


Caracas, Abril de 2011

16
I N G . L U I S G . U R I B E C
INGENIERÍA CONFINADA A SU CIRCUNSTANCIA, UNA VISIÓN EMPRESARIAL

ANEXO A: PERSONAL ASIGNADO A TIEMPO COMPLETO


AL PROYECTO “ELECTRIAHORRO” DURANTE 30 MESES

INGENIEROS: 
01 Adriana De Amicis, Ing. Electricista USB, SOPORTE al Cliente, Instalaciones 
02 César Monagas,     Ing. Electricista USB, Gerente de Producción 
03 Delfín Araújo,     Ing. Electrónico UCV,  COMUNICACIONES IaM; Aplicaciones 
04 Jorge Gonzalez rip,Ing. Electrónico USB,  HARDWARE IaM 
05 José Luis Rojas,   Ing. Electrónico USB,  Gerente de Ventas 
06 Juan Serrallonga,  Ing. Electrónico USB,  Gerente General 
07 Luis Alvarado,     Ing. Electrónico UJav, Asesor GENERAL: H/W‐S/W, producto 
08 Luis Cortez,       Ing. Electrónico USB,  Software MEDIDOR IaM, Gerente Proyecto 
09 Luis G. Uribe,     Ing. Electrónico UJav, Subproyecto !MAILER 
10 Rino Pesce,        Ing. Electrónico UCV,  Diseño Página Web 
 
PERSONAL TÉCNICO: 
11 Josefa Rodriguez,   TSU, Diseñadora Mecánica 
12 Carlos Brito,       Técnico Instalaciones 
13 Pablo Luis Aguilar, TSU Instalaciones 
 
ADMINISTRACIÓN: 
14 Ricardo Aguilar,   Contador UCV, Gerente de Administración 
15 Carmen Aguilar,    Secretaria de Gerencia General; RRHH 
16 Marianela Salazar, Contadora 
17 Norberto Monagas,  Almacenista 
 
SOLDADORES Y OTROS: 
18 Carmen,  Soldadora 
19 Ligia,   Soldadora 
20 Matilde, Sra. del Aseo 
21 Recepcionista 
 
ASESORES EXTERNOS: 
22 José Luis Rey,    Ing. de Computación USB, Diseño Software Servidor 
23 Elmer Sorrentino, Ing. Electricista   USB, Algoritmos de Medición 
 
 
(Hasta donde me alcanza la memoria…) 
 

17