En el artículo, a pesar del hecho de que es, por supuesto, relaciones públicas puras y habla sobre nuestro nuevo producto genial (opinión del autor), traté de describir nuestra experiencia útil.
¿Qué problemas encontramos nosotros y nuestros clientes al organizar el desarrollo remoto de software para dispositivos, cómo se resolvieron y de qué manera Redd, el complejo de software y hardware del desarrollo remoto de software para sistemas integrados, "creció"? ¿Por qué apareció esta "caja" y cómo cambiará la vida (nuevamente, según la opinión del autor) de millones de desarrolladores de sistemas integrados, dispositivos de Internet de las cosas, equipos para automóviles, aviones, comunicaciones.
Trabajo para una empresa que se llama modestamente
MIR . No confunda con el sistema de pago, no tenemos ninguna relación con él.
WORLD en nuestro caso significa Taller de herramientas de desarrollo.
Desarrollamos software de sistema para clientes rusos y extranjeros. Un cliente típico es un fabricante de microcontroladores y microprocesadores, generalmente con algunos no estándar, extendidos en relación con el estándar, y tal vez con su propia arquitectura.
Para ellos, desarrollamos herramientas de desarrollo: IDE, compiladores, sistemas operativos en tiempo real, depuradores, simuladores, perfiladores y otros componentes del SDK.
Paralelamente, también estamos asumiendo el desarrollo de software para sistemas integrados. Por ejemplo, para el fabricante de automóviles alemán, creamos software para paneles modernos. También realizamos proyectos de aviónica, desarrollamos software para organizar redes de malla desde medidores inteligentes y drones, hacemos software personalizado para sistemas de control de acceso y trabajamos en el mercado de IoT (enchufes inteligentes, por ejemplo). En general, hay muchos proyectos interesantes en los que resulta obtener una experiencia bastante no estándar en la resolución de problemas emergentes.
Para los clientes, somos desarrolladores externos. Además, estamos ubicados en San Petersburgo, Veliky Novgorod y Krasnoyarsk, y nuestros clientes están en Moscú, Zelenograd, Tula, Voronezh, Alemania y Corea.
Al mismo tiempo, desarrollamos software para dispositivos. Y para programar un dispositivo específico, es necesario que el programador tenga este dispositivo.
Si alguien de repente no está familiarizado con la "tecnología": necesita una computadora que funcione donde estén instaladas las herramientas de desarrollo necesarias, como el IDE. Los dispositivos deben estar conectados a la misma computadora: tableros de depuración, tableros (si hablamos de desarrollo para automóviles). Se ve algo así como en la imagen:
El desarrollador escribe el código en la computadora y lo descarga en el dispositivo donde se ejecuta.
Está claro que sin el dispositivo en sí es imposible verificar la operatividad, es imposible depurar u optimizar. Además, es importante que el programador vea qué está sucediendo físicamente con el dispositivo: qué LED parpadean, qué se muestra en la pantalla, dónde gira la rueda.
Problemas del desarrollador
Y aquí comienzan los problemas.
El primero que encontramos es la disponibilidad de equipos.
Muchas empresas hacen piezas únicas en las primeras etapas de producción. Simplemente están físicamente en el mundo, hay una, dos o cinco piezas. Transferirlos a un desarrollador externo (para nosotros) es un gran problema y una tarea difícil para el cliente. Puede que simplemente no haya dispositivos libres.
Por ejemplo, como es el caso con el nuevo procesador 1967044 de JSC PKK Milander. Todavía está en un estado de finalización del TOC, pero las herramientas de desarrollo para ello deben hacerse ahora.
El segundo problema , cuando hay pocos productos, surgen muchos problemas de hardware en ellos. Y, si el producto nos llegó desde Moscú, y encontramos un error en el hardware, podemos transferir el producto al fabricante para su corrección dentro de un día. ¿Y si el producto viniera de Alemania? Debe devolver el producto al desarrollador, esperar las correcciones y volver. Todo esto no es ni rápido ni costoso. Y todavía hay tiempo de inactividad para los programadores y los plazos de los proyectos se modifican mientras esperamos el dispositivo corregido. Y también hubo clientes que transportaron el dispositivo solo personalmente por razones de seguridad. Sin embargo, los errores de hardware suelen ser mucho más comunes de lo que pueden permitirse.
En general, la presencia de fronteras en el mundo es uno de los serios obstáculos que constantemente causan molestias. La entrega de equipos incluso desde Europa cerca de nosotros se convierte en una búsqueda, pero desde Corea o EE. UU. ... No especificaré los problemas que surgen y cómo resolverlos, solo puedo decir que todos aumentan el tiempo y el costo de los proyectos para el cliente. Eso significa que reducen nuestra competitividad.
Otro problema es que el equipo puede romperse. El transporte es un aumento en el riesgo de daños al equipo, además de la pérdida de tiempo y costos de logística. El equipo debe estar desconectado, empaquetado, transferido, desempaquetado, conectado y configurado, incluido en los soportes.
Ahora imagine que está desarrollando un analizador de gases, que viene con varios cilindros enormes y pesados ...
o un sistema de pulverización para un helicóptero.
Ahora la depuración de tales sistemas debe hacerse en emuladores, aunque sería mucho más conveniente verificar algunas cosas de forma remota (por ejemplo, el control PID del motor de pulverización, cuando el cliente al comienzo de la temporada experimenta con la instalación de motores de inyección o carburador, o retuerce las resistencias variables en su sistema de control) .
Pero surgen problemas incluso si los programadores están en el mismo edificio.
El equipo se puede "perder" si no hay procesos de transferencia formales y se realiza entre programadores dentro del proyecto. O el equipo puede "ir" al desarrollador durante mucho tiempo si hay procesos formales, pero son burocráticos. No puedo decir que realmente perdimos el equipo del cliente, pero hubo situaciones en las que no estaba claro quién tenía exactamente el tablero de depuración en este momento y cuánto tiempo estaría ocupado. La situación no es crítica, se resuelve en cinco minutos, pero hay muchos proyectos. ¿Por qué gastar tiempo extra?
El asunto se complica por el hecho de que los programadores son personas muy adictas. Como resultado, si hay competencia entre ellos por la misma tarifa (y esto sucede a menudo, ya que trabajamos principalmente con hardware único), entonces las "superposiciones" temporales y el tiempo de inactividad para los empleados que lo esperan son inevitables.
E incluso si es un líder brillante y desarrolla un excelente proceso y logística, aún perderá eficiencia al resolver una solución de programación remota sin moverse.
Por ejemplo, en tal caso. En la etapa final de desarrollo, comienzan las pruebas. Y no va después, sino en paralelo con el desarrollo, en un ciclo. Los probadores verifican las funciones realizadas, encuentran errores, luego los programadores corrigen errores, luego se necesitan pruebas, etc. Los desarrolladores y evaluadores necesitan equipos dentro del mismo proyecto. Y si sus oficinas están ubicadas, por ejemplo, en Krasnoyarsk y en Veliky Novgorod, el equipo puede funcionar casi todo el día. De día y de noche (en Moscú), los programadores de Novgorod escriben el código, y luego temprano en la mañana (ya que la diferencia es de 4 horas), los probadores de Krasnoyarsk se conectan y prueban completamente el mismo equipo durante sus horas de trabajo.
Solución tradicional
La conclusión es obvia: trabajar con hierro de forma remota puede ser muy rentable. Debe colocar todo el hardware en un solo lugar y dar acceso remoto al equipo.
Los desarrolladores se turnan para conectarse al dispositivo, trabajar con él, completar la tarea y desconectarse, liberando espacio para el siguiente.
Y todo en este esquema sería excelente, pero el uso de acceso remoto estándar a una computadora que está conectada al producto no funciona.
En la mayoría de los casos, no es
posible utilizar diferentes interfaces para conectar hardware: generalmente una computadora tiene un conjunto limitado y es imposible conectarse directamente a la placa de depuración sin adaptadores. Por ejemplo, deberá comprar un programador que permita la conexión remota.
Si aún logra conectarse, entonces el desarrollador
no podrá controlar la configuración de energía del dispositivo: es curioso no reiniciar el dispositivo. Para presionar el botón de encendido / apagado o desconectar el cable de alimentación, deberá llamar a un colega en la oficina para que vaya y lo haga a mano.
Y luego, un colega a quien el programador "golpeó el pensamiento" tendrá que volver a él durante 5-10 minutos, esto no cuenta el tiempo que estuvo corriendo y le explicaron en el teléfono qué interruptor debía tirar. Por lo tanto, ejecute horas hombre y docenas de horas hombre inactivas a la vez en varios proyectos que no están relacionados con el actual.
Además,
no está claro qué le sucede físicamente al dispositivo . Lo que se muestra en la pantalla o los indicadores del dispositivo desarrollado, cómo parpadean los LED. No siempre es necesario, pero tal necesidad generalmente surge en el momento más inoportuno.
Por supuesto, hay una opción para tratar de eludir estas limitaciones. Compre un relé controlado de forma remota para que sea posible reiniciar el dispositivo, una cámara web para monitorear, montarlo todo y configurarlo. Además, si logramos transmitir a todos cómo trabajar con esto, dónde “entrar” y qué hacer en el orden correcto, entonces nos acercaremos a la solución ...
Excepto que cuando hay más desarrolladores que dispositivos, no
hay una organización centralizada y clara del proceso de acceso . Y cuando trabaje con el equipo, tendrá que acordar de alguna manera por separado quién y cuándo trabaja con el equipo.
Redd - complejo de programación remota
La idea de resolver todos los problemas expresados de manera integral yacía en la superficie, e incluso al principio no podíamos entender por qué nadie había hecho algo así cuando comenzamos a buscar competidores. Encontramos algunas soluciones, pero inferiores, en partes. Todo el mundo hace algo en su campo: alguien que depura puramente JTAG, alguien que emula, pero también necesita depurar, y ser, y observar, y poder, y control de acceso. En el complejo, nadie lo hace, respectivamente, y no hay soluciones totalmente funcionales.
Por lo tanto, comenzamos a desarrollar Redd (significa Dispositivo de desarrollo remoto). Este es un complejo de hardware y software que organiza el acceso a equipos microelectrónicos a través de Internet o una red local utilizando una serie de protocolos de comunicación estándar y personalizados.
No buscamos "nano innovaciones". De hecho, Redd es simplemente tecnologías comprensibles y simples combinadas en un dispositivo, que en total dan una solución a los problemas que describí anteriormente.
Redd puede conectarse al dispositivo a través de varias interfaces, lo que elimina el problema de trabajar con una gran cantidad de dispositivos, sabe cómo administrar la energía y ahora puede reiniciar el dispositivo sin ninguna ayuda. Hay una cámara de video a través de la cual el desarrollador ve lo que está sucediendo con el dispositivo en tiempo real.
Además, la parte del servidor del producto le permite reservar equipos a través de la interfaz del calendario y controla el acceso.
Técnicamente, Redd consta de dos componentes dependientes: un "terminal remoto" y un software de servidor.
El terminal remoto es una computadora compatible con PC basada en el procesador Intel, equipada con una placa de expansión de interfaz, que nosotros mismos estamos desarrollando. En la primera versión (en marzo), estarán disponibles Ethernet y USB Host (JTAG). En el segundo (en junio): UART, Ethernet, GPIO, SPI (flash + SPI), SDIO (con un adaptador para un emulador de tarjeta SD), I2C, USB 2.0 OTG, PCIe, LVDS, RS232 CMOS, interruptores de alimentación para conmutación de alimentación y lógica teclas de activación, por ejemplo, botones.
El dispositivo tiene el conjunto de interfaces más comúnmente utilizado, además hay un FPGA para implementar cualquier cosa no estándar. Dado que el sistema está diseñado en un complejo, se garantiza la ausencia de conflictos mutuos. Y las interfaces irán de proyecto en proyecto junto con el complejo, sin la necesidad de comprar algo adicional.
UPD: así es como se ve una placa externa con conectores de interfaz Redd. Se "pega" en el conector del panel frontal y permite el uso de interfaces estándar. Aunque también es posible una variante, que se muestra en otras fotos, sin un tablero.
El equipo desarrollado a menudo es imposible de probar constantemente en condiciones de combate. Un helicóptero solo paga 50 euros por el soporte de despacho para el despegue y el aterrizaje. Conducir un automóvil todo el tiempo no es realista. Los barcos no siempre están en el mar. En general, necesitamos emuladores.
¿Cómo se comunica el sistema con el mundo exterior? A través de sensores conectados a varios autobuses. Bueno, las señales a los actuadores también se emiten en los autobuses. La gama actual de neumáticos es bastante amplia. Esto puede ser CAN, UART (en la versión CMOS, RS232, RS485), Ethernet, MODBUS (a través del mismo UART o Ethernet), líneas digitales con diferentes niveles, etc., etc.
Una solución típica es hacer emuladores de sensores y actuadores conectándolos a los buses. El equipo en desarrollo considerará que recibe información real, y el desarrollador imitará varios escenarios de trabajo real, depurando algoritmos de trabajo. Por supuesto, para cada proyecto, puede comprar controladores de varias interfaces y conectarlos.
O puede conectar Redd en lugar de estos sensores e intérpretes, escribir simuladores de su trabajo (es decir, simular el entorno externo) y luego depurar el dispositivo en desarrollo que cree que está en el automóvil o en otro lugar, y lo hacemos depuración de la lógica de destino. Y los probadores a través de este mecanismo podrán verificar situaciones límite e incluso deliberadamente erróneas que son muy difíciles o completamente imposibles de reproducir en pruebas ordinarias.
La parte del servidor del complejo está ubicada directamente en la terminal. El desarrollador a través de la web puede ver qué dispositivos y a qué hora están disponibles para él. Puede reservarlos en un calendario para que se le otorgue acceso automáticamente. Se conecta a través del protocolo ssh al terminal y, con él, al depurador y a la gestión de emuladores de dispositivos. Además, el modo de operación de Redd puede ser no solo multiusuario, sino también con la conexión simultánea de varios dispositivos.
Por lo tanto, Redd permite organizar el acceso remoto de desarrolladores internos o externos a un dispositivo (o un grupo de dispositivos, es posible conectar varios dispositivos a un terminal), planificar y administrar el acceso a lo largo del tiempo, sin movimiento físico.
Una bonificación adicional: Redd también se puede utilizar para demostrar el producto a clientes externos y clientes sin una transferencia real. O para organizar la programación de dispositivos de aprendizaje a distancia, que puede ser interesante para los fabricantes de microprocesadores o para las instituciones educativas.
Que ahora
Ahora estamos terminando el desarrollo de la primera versión, que se lanzará a principios de marzo, y ya está
disponible para pre-pedido (por supuesto, en términos preferenciales).
El objetivo principal de este artículo (a excepción de la publicidad) es recopilar comentarios.
Escriba si no está de acuerdo con que hay problemas que se describen en el artículo, o puede nombrar los problemas que olvidé.
Quizás conozca una solución que no hemos encontrado o resuelva estos problemas a su manera.
O están listos para apoyarnos con una palabra amable (o tal vez no solo) en el desarrollo de productos.
Estaré encantado de comentar.