Diseños modulares multiplataforma

Desde los años 80 he realizado tareas de diseño y desarrollo de soluciones electrónicas embebidas. Comenzando en el área de producción, pasando por diseño, hasta la co-dirección externa de departamentos de I+D, he vivido el día a día de la evolución en el sector electrónico; no he hecho otra cosa durante más de 30 años.

La electrónica embebida, ahora IoT para entendernos, ha tenido una crecimiento meteórico. Todo a nuestro alrededor es “inteligente” y está conectado. Hemos pasado de soluciones en las que todas las tareas las podía realizar uno o dos ingenieros, a equipos multidisciplinares con directores y especialistas para cada área.

Esta introducción da pie a diversos y apetitosos temas que trataré próximamente, hoy voy a centrarme de manera resumida en la vida y evolución del producto y en como las soluciones modulares multi-plataforma son la respuesta a los cambios, cada vez más rápidos, que se producen en el hardware para los sistemas embebidos.

internet

En este momento nadie debería creer que un diseño de hardware se podrá fabricar “tal cual” durante 3 o 5 años, es muy difícil y la lista de porqués enorme, incluyendo las famosas asignaciones (allocation).

Esto es un problema, tanto para el pequeño como para el gran fabricante, pero se puede convertir en un drama si el desarrollo no lo contempla. Cuanto más compleja es la solución, más expuesta está a los vaivenes en el mercado de los componentes.

Por lo tanto un requerimiento no funcional de cualquier diseño actual es que sea sencillo y portable. Para conseguirlo debemos fragmentar el sistema en módulos y diseñar y desarrollar el firmware o software multiplataforma.

Con esta receta podremos asegurar la fabricación y servicio post venta durante la vida del producto.

Ah, me olvidaba, si eres externo/a, intégrate en el equipo del cliente porque sólo así podrás conseguir el objetivo!

 

Anuncios

Cómo y por qué externalizar I+D

Lo primero que debemos plantearnos antes de externalizar, es si el área que estamos pensando externalizar tiene un impacto directo en nuestro valor como empresa. No tiene sentido dejar en manos de terceros algo que supone el motor mismo de nuestra empresa. Tampoco tiene sentido asumir esa función interna si no es fundamental o si terceros pueden hacerla mejor de manera más eficiente.

idea_emb

 

Los principales factores que impulsan a externalizar incluyen presiones continuas del mercado para reducir costes, acortar el tiempo de comercialización y dominar la complejidad de las tecnologías. El Outsourcing permite a los OEMs concentrarse en sus competencias básicas, que incluyen innovación, ventas y marketing.

En la economía todo se considera externalizable, incluyendo la investigación y el desarrollo (I+D), hasta la innovación en sí misma. El outsourcing de I+D+i no es realmente una nueva idea o tendencia. Desde hace años las empresas externalizan este área para centrarse en el core de su negocio.

Las empresas externalizan I+D para obtener más conocimientos, personal cualificado con experiencia y para ofrecer un nuevo producto en el mercado en un tiempo más corto. Por lo tanto, las funciones de I+D que externalizar incluyen diseño, innovaciones, nuevos productos y nuevos procesos.

No hay que confundir externalizar con perder la propiedad intelectual. Las empresas de outsourcing nos ayudarán a impulsar el desarrollo y la innovación, pero el OEM debe seguir liderando este área manteniendo una visión global del producto. Sin embargo y a pesar de las dificultades, la externalización de actividades de I+D+i está aquí para quedarse.

 

Externalizar para impulsar

Confiar a una empresa externa proyectos de diseño electrónico, críticos en costes y tiempo, quita el sueño a muchos directores. Por el miedo a externalizar y a perder el control deciden emprender un proyecto que está fuera de la experiencia de su equipo interno y mientras la competencia libera productos al mercado, ellos todavía están navegando por la curva de aprendizaje.

hazlo-tu-mismo

El proceso de desarrollo

El proceso de diseño y desarrollo debe gestionarse de tal manera que sea posible controlarlo sin reducir la creatividad.

Los procedimientos de diseño y desarrollo deben personalizarse y ayudar al flujo general del trabajo en lugar de entorpecerlo. Sin embargo, hay ciertas actividades que puede considerarse superfluas o menores que deben realizarse para garantizar el objetivo.

FullDesignProcess

Estas son algunas de las actividades principales

Inicio del proyecto

Este es una de las actividades más relevantes porque es especialmente importante dirigir el proyecto en la dirección correcta.

  • Capturar requisitos
  • Definir el producto
  • Pruebas y viabilidad
  • Estimación de costes
  • Definir requisitos
  • Revisión

 

Diseño y desarrollo electrónico

Es el área donde se realiza el trabajo principal en la creación de producto. Es probable que el equipo del proyecto esté en la fase de mayor intensidad.

  • Diseño de hardware
  • Desarrollo de software
  • Diseño mecánico
  • Diseño PCB
  • Estrategia de pruebas y producción
  • Construir prototipos
  • Pruebas de desarrollo
  • Revisión

Integración, verificación y validación

Producción

Mantenimiento

 

 

Portabilidad y reaprovechamiento

En la actualidad para ser competente es necesario poder desarrollar rápidamente una aplicación y permitir la migración entre diferentes plataformas incompatibles entre sí. Para lograrlo es fundamental poder reaprovechar la máxima cantidad de código posible, y no tener que “inventar la rueda” cada vez que el producto evoluciona o se plantea una nueva plataforma.

Hemos desarrollado una metodología en la que, a partir de un único código base principal, facilitamos el uso de varios lenguajes de programación en diferentes sistemas operativos.

Partimos de una librería dinámica escrita en C portable multi-plataforma que concentra el núcleo de la funcionalidad del sistema, dejando fuera la interfaz de usuario. A petición del cliente generamos una versión nativa de esta librería para Windows de escritorio, Windows CE / Compact / IoT, Linux, IOS o Android (mediante el kit de desarrollo nativo NDK).

Portabilidad

Asimismo proveemos los módulos de adaptación necesarios para acceder a la librería nativa desde diferentes lenguajes de programación, en las que se pueden construir ricos interfaces de usuario: Java, Python y C#. De esta forma, mediante un único núcleo bien testado es posible interactuar desde 4 lenguajes de programación en 4 plataformas diferentes.

Deuda técnica

Wiki. La deuda técnica es un término tecnológico que hace referencia a las consecuencias de un desarrollo apresurado de software o una deficiente implantación de hardware.

Sectores como el informático y el electrónico presentan la particularidad de que permiten la implantación de productos no acabados o con errores conocidos.

En ocasiones, la política de ahorro de costes en el desarrollo e implantación de hardware o software se centra en recortar procesos de pruebas, control de calidad o documentación, o incluso suprimir procesos completos, lo que compromete la viabilidada a largo plazo del proyecto a cambio de entregarlo en el plazo y presupuesto acordados.

El resultado de esta política implica que el desarrollo se prolonga en el tiempo más allá de la entrega del producto supuestamente concluido.

La deuda técnica puede presentarse en alguna de las siguientes formas:

  • Documentación desactualizada, escasa, incompleta, inservible o inexistente.
  • Errores no subsanados o desconocidos.
  • Control de versiones ineficiente o inexistente.
  • Desarrollo no escalable.
  • Problemas al incorporar nuevas funcionalidades.
  • Dificultades a la hora de actualizar la tecnología o migrar a una nueva plataforma.

El término deuda técnica fue propuesto por primera vez en 1992 por Ward Cunningham. Un desarrollo pobre equivale a una evaluación de inversiones financieras basada en la obtención de beneficios a corto plazo. En el sector de la finanzas, una inversión que busca el beneficio a corto plazo puede generar deudas cuyos intereses se han de liquidar durante un periodo de tiempo muy prolongado.

2000-01-01 00.10.56

De forma análoga, un desarrollo tecnológico apatentemente corto puede requerir un esfuerzo extra para subsanar los problemas generados al no aplicar una adecuada metodología de desarrollo. Ese esfuerzo extra, que puede multiplicar el tiempo de desarrollo del proyecto inicial, equivaldría a los intereses de una deuda financiera.

La dedua técnica no siempre indica algo mal echo. En ocasiones esta deuda permite satisfacer unos requisitos y cumplir con una entrega pactada. Lo importante de esta deuda técncia intencionada es documentarla y gestionarla para más adelante dedicar tiempo a eliminarla.

Es muy importante documentar la deuda técnica. Cuando en un desarrollo sabemos que hay algo que debemos revisar, mejorar y refactorizar, esta deuda técnica debe estar documentada para que lo responsables puedan tomar las decisiones oportundas sobre cómo y cuándo ir quitándonos esa deuda.

También se toman decisiones, anivel de arquitectura inapropiada por ejemplo, que generan una cierta deuda técncia.

 

 

 

 

Metodología, el factor de éxito más determinante

Con el objetivo de minimizar riesgos y ofrecer un servicio de calidad, NMI Electronics utiliza un marco de buenas prácticas, orientando a procesos, mediante el cual, conseguimos coordinar a todos los colaboradores del proyecto hacia el objetivo común, asegurando el éxito en el plazo y coste previsto.

methodology1

 

Diseño modular
Nuestros diseños siempre se basan en el uso de componentes funcionalmente independientes. Esto nos permite ofrecer un software que es fácilmente mantenible y ampliable sin poner en riesgo su estructura, y un desarrollo rápido ya que los componentes son reutilizables en diferentes proyectos.

Seguridad
Los proyectos se alojan en un servidor Trac privado, lo que nos permite trazar todo el histórico de cambios y versiones, y con copias de seguridad automáticas para evitar una pérdida accidental de los proyectos.

Transparencia
Nuestros clientes siempre tienen acceso a su proyecto en el servidor, con lo que pueden observar en tiempo real cómo avanza el desarrollo de su aplicación y en qué punto se encuentra.

Colaboración
Groupware para la gestión y desarrollo de los proyectos. Facilita y estimula la cooperación dentro y fuera de la organización ayudando a los equipos a comunicarse y colaborar en proyectos comunes independientemente de la ubicación de sus miembros.

Documentación en código
Si el cliente así lo desea, documentamos todo el código en el formato necesario para poder exportarlo mediante Doxygen.

http://www.nmielectronics.com