Cómo organizar el desarrollo distribuido, si esto no es posible

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.

Source: https://habr.com/ru/post/440156/


All Articles