DRAFT DE SISTEMAS ELECTRÓNICOS COOPERANTES.

Elaborado por: Jorge Nava Amador.

Revisado por:

Versión: 16 de abril 2018

1. Consideraciones para Definición del Problema.

 La carrera de ingeniería electrónica dispone de un currículo definido en el año 2000,
consiguientemente se tiene 18 años de aplicación de la referida malla curricular, con
tres menciones como las Telecomunicaciones, Sistemas Computacionales y Control.
 La curricula estuvo y está concebida para que los docentes pueden rotar cada cierto
tiempo entre las asignaturas de su mención, no obstante las rotaciones estuvieron
limitadas a algunas asignaturas y docentes.
 Asimismo, la asignatura de Proyecto de Grado debió coordinar los trabajos de cada
uno de los docentes de una misma mención con la finalidad de que las interacciones
entre asignaturas permitan no duplicar contenidos y mejoren las interacciones dentro
de las menciones. Este trabajo no ha sido concluido, lo cual incide en la falta de
coordinación de contenidos entre asignaturas dentro de una misma mención.
 En las últimas gestiones de la carrera se fortalecieron los laboratorios de estas
menciones, así como se dinamizó la investigación en el Instituto de Electrónica
Aplicada, no obstante estos esfuerzos traerán resultados en el transcurso de los
siguientes años.
 Debido a los aspectos anteriores, las interacciones entre menciones están ausentes y
más aún entre las carreras de la universidad, lo cual impide adquirir experiencia en la
interacción entre disciplinas afines o complementarias para la realización de proyectos
conjuntos.
 Uno de estos casos se observa en los estudiantes de la mención de Control, quienes
enfrentan desafíos de tener que buscar alternativas de formación en Sistemas y
Telecomunicaciones o recurren a actividades autodidacticas, con los consiguientes
riesgos que ello conlleva.
 Otro de los inconvenientes que se observa es que los estudiantes no están
acostumbrados a realizar trabajos en equipo, bien porque dejan que el trabajo
realicen unos cuantos o bien porque no tienen afinidades, estos aspectos
acompañados por la falta de organización, dificultan el logro y cumplimiento de
objetivos con calidad.
 Otro gran ausente es la falta de aplicación de metodología de trabajo en el desarrollo
de los trabajos experimentales, de laboratorio o proyectos iniciales de ingeniería. Los
estudiantes si bien durante la formación tienen tres asignaturas de Proyecto (Proyecto
I, Proyecto II y Proyecto de Grado), así como Evaluación de Proyectos, Seminarios y
otras como Estrategia Empresarial, durante los diez semestres; en ninguna de ellas
parecen ver cuáles son las consideraciones que deberán tener para la realización de un
Proyecto de Ingeniería, es posible afirmar esto en base a la calidad de los trabajo de
 grado que se observan, los cuales tienen una variedad en cuanto a la estructura y
abordaje de su contenido.
 No obstante, los estudiantes deben adquirir habilidades y destrezas en la realización
de proyectos de ingeniería, identificando las etapas del ciclo de vida de un proyecto.
En sus proyectos de grado, bien se quedan en los requerimientos, en el diseño, o en la
implementación de un prototipo.
 Es necesario incorporar buenas prácticas (best practices) en la formación de los
estudiantes de ingeniería, y una alternativa puede ser aplicar aquellas que se observan
en la Ingeniería de Software, donde se buscaron alternativas para el desarrollo de
proyectos que tengan una adecuada organización, etapas del ciclo de vida claramente
identificadas, aplicación de estándares, generación de documentación, que permitan
una adecuada gestión y administración del proyecto, así como la toma de la posta por
cualquier profesional o estudiante que se incorpore en una etapa intermedia del
trabajo de desarrollo, este aspecto incidirá también en los resultados con calidad del
trabajo desarrollado, así como en una mejor organización para el mantenimiento
correspondiente del producto o servicio desarrollado.
 Para la interacción con otras menciones, no se usan las plataformas que se adquirieron
y que se encuentran disponibles en laboratorio, tampoco los docentes se organizan
para buscar proyectos conjuntos entre menciones.
 Los estudiantes que se encuentran en los últimos semestres de la carrera, no disponen
de todas las habilidades para abordar proyectos que requieran del conocimiento de
contenidos programáticos de otras menciones o de temas afines con alguna de las
menciones que no han formado parte de su formación.
 Las plataformas que se disponen en la carrera, como son la de manufactura, los
manipuladores, el proceso termo-hidráulico, son plataformas que si bien tienen la
parte de control y software, no necesariamente disponen de la parte de
comunicaciones, y además en la parte de software el manejo es de bajo nivel. Además
son plataformas en las que no se tienen que efectuar ningún tipo de concepciones
adicionales, como las de requerimientos funcionales, ya que estas ya están
construidas, y no necesariamente en un proyecto de ingeniería ya se dispondrá de la
plataforma, en todo caso habrá que concebirla para resolver un determinado
problema o una problemática.
 Hay aspectos de costo que se requieren considerar para lograr el mayor beneficio con
la menor inversión.
 Los desafíos académicos no solo están orientados en la incursión de otros temas o
contenidos considerados en otras asignaturas de las menciones de la carrera de
Ingeniería Electrónica, sino también en temas que no están considerados en los
contenidos vigentes. Como por ejemplo, incursionar en:
o Ingeniería de Software para la aplicación de estrategias de desarrollo.
o Metodologías de programación para evitar realizar código espagueti.
o Definición y aplicación de protocolos de comunicación – Modelo OSI o defacto
TCP/IP.
o Sistemas embebidos o embarcados o empotrados.
o Sistemas Operativos.
o Ensambladores cruzados.
o Entornos de desarrollo IDE.
o Metodologías de desarrollo de proyectos de ingeniería, considerando los ciclos
de vida de los mismos.
 o Sistemas SCADA – Supervisory Control and Data Acquistion.
o Sistemas DCS – Distributed Control System o Sistemas de Control Distribuido.
o Sistemas distribuidos.
o Sistemas de control jerárquico.
o Control digital.
o Sistemas de Información, bases de datos en tiempo real.
o Ingeniería de Requerimientos – Estándar IEEE.
o Integración de los sistemas de control empresarial (equipamiento de campo,
control de procesos, operación y supervisión, manufactura y administración) –
Estándar ISA 95.
o Sistemas de Administración empresarial – ERP )Planificación de Recursos de la
Empresa) y CRM (Sistemas de gestión de relacionamiento con el cliente).
o Sistemas EMS - Energy Management System o Sistema de Administración de
Energía.
o Sistemas MES - Manufacturing Execution System o Sistemas de Ejecución de
Manufactura.
o Sistemas de Operación y supervisión (Sistemas SCADA, DCS).
o Sistemas para Control de Procesos (PLC, RTU).
o Equipos de Campo (Identificación de transductores aplicables a la medición y
al accionamiento necesario, Instrumentación, electrónica de potencia).
o Sistemas de comunicación guiados y no guiados.
o Equipamiento de campo.
o Lenguaje unificado de modelado – UML.
o Rational Unified Process – RUP.
o Computer Integrated Manufacturing – CIM.
o Industrias o procesos por Lotes, Continuos, Repetitivos o Discretos.
o Entre otros.
2. Objetivo.
 Desarrollar una plataforma de experimentación que permita involucrar todos los
desafíos académicos identificados, donde inicialmente concurran los conocimientos y
aplicación de las asignaturas de Sistemas de Control II, Aplicación de Técnicas de
Control, Bases de Datos, Ingeniería de Software, Programación, Interacción Hardware
Software, Microprocesadores.
3. Propuesta de solución.
 Concebir un sistema electrónico autónomo, centralizado, supervisado, controlado,
distribuido, conformado por un puesto central, red de comunicaciones y unidades
remotas.
o Un puesto central, dotado de un sistema de gestión de la información, para
configurar y supervisar de manera continua el trabajo y estado que
desempeñan cada una de las unidades remotas. Este sistema deberá tener
además una configuración de respaldo que permita la conmutación de
funciones sin la perdida de comunicación y recolección de estados con las
unidades remotas.
o Una red de comunicaciones privada, mediante la que a través de un sistema
de comunicaciones guiado o no, se puede mantener comunicación
permanente entre las unidades remotas y el puesto central, así como entre las
propias unidades remotas.
 o Unidades remotas, capaces de interactuar autónomamente o supervisadas por
la unidad central y que tengan los subsistemas necesarios que les permitan
aplicar la técnica de control con las que alcancen el mejor desempeño. Cada
una de estas unidades estará conformada como un sistema embebido, en el
que las características mecánicas, eléctricas, electrónicas y funcionales sean
las mismas.
4. Metodología de trabajo.
 Se trabajara bajo la metodología RUP.

 Documentando todo el proceso con UML.

 El Proceso Unificado se compone, entre otras cosas, de 4 fases:

o En la primera fase de Iniciación (Gestación o Concepción), se recoge el alcance
del proyecto y su razón de ser.
o En la segunda fase de Elaboración (Preparación), se incluyen requisitos más
detallados así como descripciones de alto nivel, análisis y diseño a grandes
rasgos que permitirán crear un plan de Construcción.
 En el diseño del sistema, para cada uno de los subsistemas, se decidirá
la estructura de clases de manera que en la siguiente iteración se
puedan implementar las partes de una forma lo más independiente
posible, lo cual permitirá realizar pruebas generando para tal efecto
un diagrama que lo aclare.
 El diseño de la interfaz de usuario de la aplicación se centra en temas
de interacción con el usuario (posiblemente para cada uno de los
subistemas), lo que permitirá recoger las clases y artefactos necesarios
para que la aplicación sea utilizable. Se generarán también para tal
efecto diagramas de Casos de Uso.
o En la tercera fase de Construcción, se seguirá un desarrollo iterativo e
incremental (similar al desarrollo en espiral de la Ingeniería de Software), y la
notación a utilizar en los distintos diagramas será el estándar UML. Para cada
 iteración se seleccionarán algunos Casos de Uso, se refinará el análisis y el
diseño y se procederá a su implementación y pruebas.
 Se realizarán las iteraciones necesarias hasta que se termine la
implementación de la nueva versión del producto, focalizándose en
solucionar lo planteado sin extender o modificar (en la menor medida
posible), los diseños iniciales.
 Las pruebas se realizarán en cada iteración para evitar arrastrar
errores y disminuir futuros riesgos.
o Tanto la documentación como las pruebas se irán completando para cada
iteración, incluyendo cualquier clase de información técnica relevante.
o En la cuarta fase de Transición, se pretende garantizar que se tiene el
producto terminado y listo para su entrega. Los diferentes manuales, se
realizarán en esta fase y se tratara de sintetizar el funcionamiento del sistema
desde el punto de vista de los usuarios o clientes de la aplicación.

 El proceso iterativo e incremental de RUP está caracterizado por la realización en

paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo cual la
mayoría de los artefactos son generados muy tempranamente en el proyecto pero van
desarrollándose en mayor o menor grado de acuerdo a la fase e iteración del
proyecto.

 En cuanto a los componentes del proceso, se deben considerar:

  Los grupos de trabajo estarán conformados por estudiantes de la mención Control y
Sistemas Computacionales.
Grupo
ETN 902
Duran Sullcamani Richard Jhony.
1 Mamani Mamani José Carlos.
Gisbert Castro Daniela Florencia
Renjifo Tarquino Roger.
2 Poma Laura Omar.
Linares Porcel José Leonardo.
Nieto Coronel Joel Gastón.
3 Calle Linares Juan Javier.
Acarapi Quispe Rodrigo Ronald.
Callejas Marín Luis Fernando.
4 Condo Merlo Ronald Etson.
España Ulloa Joel Bautista.
Estudiantes
ETN 1000
Jurado Camacho Martin Miguel.
Alarcón Contreras Aldo Arturo.Ríos.
Auxiliar de Base de Datos.
Mita Limachi Antonio.Ballesteros.
Gonzales María Cecilia.
Collo Mollo Anaid Maribel.
López Daniel Ernesto.
Claure Marín Carmen Ximena.
ETN 1034
Alarcón Coss Coaquira Carlo Inti.
Mollericon García Jorge Luis.
Gutiérrez Tola Ronald Gabriel.
Humerez Morales Álvaro Kevin.
Calderón Antezana Raniero Humberto.
Roldan Illanes Belén Marcia.Claure.
Osco Chacón Grover Wilson.
Aliaga Rojas Bismarck.
Limachi Pardo Edwin.
Marín Carmen Ximena.
Loayza Almonte Wendie Caterin.
Ibáñez Quispe Kelly Roxana.

5. Consideraciones para el Modelo del Negocio y la Captura de Requisitos.

 El sistema debe contar con el puesto central, comunicaciones y unidades remotas.
 El sistema central deberá configurar a cada una de las unidades remotas.
 Las unidades remotas deben seguir una determinada trayectoria y además deben
alcanzar un objetivo en el menor tiempo y con el mínimo en el uso de recursos.
 Cada unidad remota debe informar sobre su estado en cuanto a posición actual y el
estado de sus unidades funcionales.
 Entre las unidades deben cooperarse para alcanzar un objetivo.
 El sistema de comunicaciones, debe utilizar un protocolo de aplicación de para y
espera (stop and wait).
 Se debe considerar la concepción bajo el estándar ISA 95:
6. Plan y Cronograma de trabajo.
 El plan de desarrollo programado, se revisará semanalmente y se refinará antes del
comienzo de cada iteración

Dedicación y Calendario
Fase Semanas Plazo Límite
1 Fase de Inicio-Gestación 1 24 de abril
2 Fase de Elaboración 2 8 de mayo
3 Fase de Construcción 6 19 de junio
4 Fase de Transición 1 26 de junio
7. Documentación del proyecto.
 La documentación de este proyecto estará compuesta de:
o Manual técnico del proyecto con las siguientes secciones:
 Instalación, configuración y administración del sistema.
 Programación e incorporación al sistema de nuevos componentes o
módulos.
 Tutorial de uso del sistema o la aplicación para administradores y
usuarios del sistema.
o Memoria del proyecto, incluyendo las siguientes secciones:
 Introducción (visión general, objetivos, descripción del sistema,
tecnologías).
 Planificación (planificación temporal, estimación de costes).
 Análisis:
 Especificación de requisitos.
 Funciones del sistema.
 Modelo de casos de uso.
 Diseño:
 Diseño detallado de casos de uso.
  Modelo de datos (por ejemplo):
 Diagrama entidad-relación.
 Tablas de bases de datos y descripción.
 Modelos de controladores.
 Modelo de actuación con campo.
 Modelo de comunicaciones.
 Implementación:
 Arquitectura física del sistema.
 Organización y estructuración del sistema y/o la aplicación.
Ejemplos de código fuente y diseño de electrónica o sistemas
electrónicos.
 Pruebas (de unidad, de integridad, de funcionalidad, de seguridad,
validación de técnicas de control, de comunicaciones, etc.)
 Conclusiones.
 Apéndice.
 Bibliografía.

8. Referencias para el desarrollo.

 Proyectos con Microcontroladores Usando Lenguaje UML
(http://www.incb.com.mx/index.php/articulos/78-microcontroladores-y-dsps/1619-
proyectos-con-microcontroladores-usando-lenguaje-uml-a002).
 La gestión de control domótico basado en la plataforma Arduino para una vivienda
(http://repository.libertadores.edu.co/bitstream/handle/11371/741/GomezJoseRigob
erto.pdf?sequence=2&isAllowed=y).
 DESARROLLO DE UN SISTEMA DE CONTROL AUTOMÁTICO DE RIEGO POR
COMPUERTAS PARA LA JUNTA DE REGANTES DE GUARANGO PAMPA - UTCUBAMBA –
AMAZONAS (http://revistas.uss.edu.pe/index.php/ING/article/view/118).
 Estándar ISA 95 (http://isamex.org/intechmx/index.php/2017/09/26/estandar-isa-95-
integracion-de-los-sistemas-de-control-empresarial/).
 ANÁLISIS, DISEÑO Y CONSTRUCCIÓN DE UN SISTEMA HIDROPÓNICO AUTOMATIZADO
PARA AUTOCONSUMO DE VEGETALES Y PLANTAS ORNAMENTALES
(http://repositorio.uchile.cl/bitstream/handle/2250/140623/Analisis-diseno-y-
construccion-de-un-sistema-hidroponico-automatizado-para-autoconsumo-de-
vegetales.pdf?sequence=1).
 RUP para sistemas electrónicos (se adjunta).