No artigo, apesar de ser, é claro, pura RP e falar sobre nosso novo produto interessante (opinião do autor), tentei descrever nossa experiência útil.
Quais problemas nós e nossos clientes encontramos ao organizar o desenvolvimento remoto de software para dispositivos, como eles foram resolvidos e de onde Redd, o complexo de software e hardware para desenvolvimento remoto de software para sistemas embarcados, “expandiu as pernas”? Por que essa “caixa” apareceu e como a vida (novamente, a opinião do autor) mudará de milhões de desenvolvedores de sistemas embarcados, dispositivos de Internet das Coisas, equipamentos para carros, aviões, comunicações.
Eu trabalho para uma empresa que se chama modestamente
MIR . Não confunda com o sistema de pagamento, não temos relação com ele.
WORLD, no nosso caso, significa Workshop of Development Tools.
Desenvolvemos software de sistema para clientes russos e estrangeiros. Um cliente típico é um fabricante de microcontroladores e microprocessadores, geralmente com alguns padrões não estendidos em relação ao padrão e talvez com sua própria arquitetura.
Para eles, desenvolvemos ferramentas de desenvolvimento: IDEs, compiladores, sistemas operacionais em tempo real, depuradores, simuladores, criadores de perfil e outros componentes do SDK.
Paralelamente, também estamos assumindo o desenvolvimento de software para sistemas embarcados. Por exemplo, para a montadora alemã, fabricamos software para painéis modernos. Também desenvolvemos projetos em aviônicos, desenvolvemos software para organizar redes mesh a partir de medidores e drones inteligentes, fazemos software personalizado para sistemas de controle de acesso e trabalhamos no mercado de IoT (soquetes inteligentes, por exemplo). Em geral, existem muitos projetos interessantes nos quais se obtém uma experiência não padronizada na solução de problemas emergentes.
Para os clientes, somos desenvolvedores externos. Além disso, estamos localizados em São Petersburgo, Veliky Novgorod e Krasnoyarsk, e nossos clientes estão em Moscou, Zelenograd, Tula, Voronezh, Alemanha e Coréia.
Ao mesmo tempo, desenvolvemos software para dispositivos. E, para programar um dispositivo específico, é necessário que o programador tenha esse dispositivo.
De repente, alguém não está familiarizado com a "tecnologia": você precisa de um computador em que as ferramentas de desenvolvimento necessárias, como o IDE, estejam instaladas. Os dispositivos devem estar conectados ao mesmo computador: painéis de depuração, painéis (se estamos falando sobre desenvolvimento para carros). Parece algo como na imagem:
O desenvolvedor grava o código no computador e o baixa no dispositivo em que é executado.
É claro que, sem o próprio dispositivo, é impossível verificar a operabilidade, é impossível depurar ou otimizar. Além disso, é importante que o programador veja o que está acontecendo com o dispositivo fisicamente: quais LEDs piscam, o que é mostrado na tela, onde a roda está girando.
Problemas do desenvolvedor
E aqui começam os problemas.
O primeiro que encontramos é a disponibilidade de equipamentos.
Muitas empresas fazem peças únicas nos estágios iniciais de produção. Eles estão simplesmente fisicamente no mundo, há uma, duas ou cinco peças. Transferi-los para um desenvolvedor externo (para nós) é um grande problema e uma tarefa difícil para o cliente. Simplesmente pode não haver dispositivos gratuitos.
Por exemplo, como é o caso do novo processador 1967 × 044 da JSC PKK Milander. Ele ainda está em fase de conclusão do TOC, mas as ferramentas de desenvolvimento para isso precisam ser feitas agora.
O segundo problema , quando existem poucos produtos, surgem muitos problemas de hardware. E, se o produto veio de Moscou e encontramos um erro no hardware, podemos transferir o produto ao fabricante para correção em um dia. E se o produto veio da Alemanha? Você precisa enviar o produto de volta ao desenvolvedor, aguardar pelas correções e voltar. Tudo isso não é rápido nem caro. E ainda há tempo de inatividade para programadores e os prazos do projeto são alterados enquanto aguardamos o dispositivo corrigido. E também havia clientes que transportam o dispositivo apenas pessoalmente por razões de segurança. No entanto, os erros de hardware geralmente são muito mais comuns do que podem acontecer.
Em geral, a presença de fronteiras no mundo é um dos sérios obstáculos que constantemente causam transtornos. A entrega de equipamentos até da Europa perto de nós se transforma em uma missão, mas da Coréia ou dos EUA ... não especificarei os problemas que surgirão e como resolvê-los, só posso dizer que todos aumentam o tempo e o custo dos projetos para o cliente. Isso significa que eles reduzem nossa competitividade.
Outro problema é que o equipamento pode quebrar. O transporte é um aumento no risco de danos ao equipamento, além de perda de tempo e custos de logística. O equipamento deve ser desconectado, embalado, transferido, desembalado, conectado e configurado, incluído nos estandes.
Agora imagine que você está desenvolvendo um analisador de gases, que vem com vários cilindros enormes e pesados ...
ou um sistema de pulverização para um helicóptero.
Agora, a depuração de tais sistemas deve ser feita em emuladores, embora seja muito mais conveniente verificar algumas coisas remotamente (por exemplo, o controle PID do mecanismo de pulverização, quando o cliente no início da temporada experimenta a instalação de motores de injeção ou carburador ou torce os resistores variáveis em seu sistema de controle) .
Mas os problemas surgem mesmo se os programadores estiverem no mesmo prédio.
O equipamento pode ser “perdido” se não houver processos formais de transferência e isso ocorre entre os programadores do projeto. Ou o equipamento pode "ir" para o desenvolvedor por um longo tempo, se houver processos formais, mas são burocráticos. Não posso dizer que realmente perdemos o equipamento do cliente, mas houve situações em que não estava claro quem exatamente possuía a placa de depuração no momento e quanto tempo ainda estaria ocupado. A situação é crítica, resolvida em cinco minutos, mas há muitos projetos. Por que gastar tempo extra?
O assunto é agravado pelo fato de que os programadores são pessoas muito viciadas. Como resultado, se houver concorrência entre eles pela mesma taxa (e isso acontece com freqüência, uma vez que trabalhamos principalmente com hardware exclusivo), inevitáveis "sobreposições" temporárias e tempo de inatividade para os funcionários que a aguardam.
E mesmo se você for um líder brilhante e criar um excelente processo e logística, ainda perderá a eficiência resolvendo uma solução de programação remota sem se mover.
Por exemplo, nesse caso. No estágio final do desenvolvimento, o teste começa. E não vai depois, mas em paralelo com o desenvolvimento, em um ciclo. Os testadores verificam as funções executadas, encontram erros, os programadores corrigem os bugs, os testes são necessários e assim por diante. O equipamento dentro do mesmo projeto é necessário para desenvolvedores e testadores. E se seus escritórios estiverem localizados, por exemplo, em Krasnoyarsk e em Veliky Novgorod, o equipamento poderá funcionar quase o tempo todo. Dia e noite (em Moscou), programadores de Novgorod escrevem o código e, de manhã cedo (já que a diferença é de 4 horas), os testadores de Krasnoyarsk se conectam e testam completamente no mesmo equipamento durante o horário de trabalho.
Solução tradicional
A conclusão é óbvia - trabalhar com ferro remotamente pode ser muito lucrativo. Você precisa colocar todo o hardware em um só lugar e conceder acesso remoto à equipe.
Os desenvolvedores se revezam na conexão com o dispositivo, trabalhando com ele, concluindo a tarefa e desconectando, liberando espaço para a próxima.
E tudo nesse esquema seria ótimo, mas o uso do acesso remoto padrão a um computador conectado ao produto não funciona.
Na maioria das vezes, não é
possível usar interfaces diferentes para conectar o hardware: geralmente um computador tem um conjunto limitado e é impossível conectar-se diretamente à placa de depuração sem adaptadores. Por exemplo, você precisará comprar um programador que permita conexão remota.
Se você ainda conseguir se conectar, ainda assim o desenvolvedor
não poderá controlar as configurações de energia do dispositivo: é brega não reiniciar o dispositivo. Para pressionar o botão liga / desliga ou desconectar o plugue do cabo de alimentação, você deverá ligar para um colega no escritório para que ele o faça manualmente.
E, em seguida, um colega para quem o programador “ignorou o pensamento” terá que retornar a ele por 5 a 10 minutos, isso não está contando o tempo em que ele estava executando e eles explicaram a ele no telefone quais opções para acionar. Portanto, execute horas-homem e dezenas de horas-homem ociosas ao mesmo tempo em vários projetos que não estão relacionados ao atual.
Além disso,
não está claro o que acontece com o dispositivo fisicamente . O que é mostrado na tela ou nos indicadores do dispositivo desenvolvido, como os LEDs piscam. Nem sempre é necessário, mas essa necessidade geralmente surge no momento mais inoportuno.
Obviamente, existe uma opção para tentar contornar essas limitações. Compre um relé controlado remotamente para que seja possível reiniciar o dispositivo, uma webcam para monitorar, montar tudo e configurar. Além disso, se conseguirmos transmitir a todos como trabalhar com isso, onde "entrar" e o que fazer na ordem correta, estaremos mais próximos da solução ...
Exceto que, quando há mais desenvolvedores do que dispositivos, não
há uma organização centralizada e clara do processo de acesso . E, ao trabalhar com a equipe, você terá que, de alguma forma, concordar separadamente quem e quando trabalha com o equipamento.
Redd - complexo de programação remota
A idéia de resolver todos os problemas expressos estava na superfície e, mesmo no começo, não conseguimos entender por que ninguém havia feito algo assim quando começamos a procurar concorrentes. Encontramos algumas soluções, mas inferiores, em partes. Todo mundo faz algo em seu campo: alguém puramente depurando JTAG, alguém emulando, mas você também precisa depurar e permanecer, observar e poder e controlar o acesso. No complexo, ninguém trabalha, respectivamente, e não há soluções totalmente funcionais.
Portanto, começamos a desenvolver o Redd (significa dispositivo de desenvolvimento remoto). Este é um complexo de hardware e software que organiza o acesso a equipamentos microeletrônicos via Internet ou rede local usando vários protocolos de comunicação padrão e personalizados.
Não buscamos “nano inovações”. De fato, Redd é simplesmente tecnologias compreensíveis e simples combinadas em um dispositivo, que no total dão uma solução para os problemas que descrevi acima.
O Redd pode se conectar ao dispositivo através de várias interfaces, o que elimina o problema de trabalhar com um grande número de dispositivos, é capaz de gerenciar energia e agora você pode reinicializar o dispositivo sem ajuda. Existe uma câmera de vídeo através da qual o desenvolvedor vê o que está acontecendo com o dispositivo em tempo real.
Além disso, a parte do servidor do produto permite que você reserve equipamentos através da interface do calendário e controla o acesso.
Tecnicamente, o Redd consiste em dois componentes dependentes: um "terminal remoto" e um software de servidor.
O terminal remoto é um computador compatível com PC baseado no processador Intel, equipado com uma placa de expansão de interface, que nós mesmos estamos desenvolvendo. Na primeira versão (em março), Ethernet e USB Host (JTAG) estarão disponíveis. No segundo (em junho) - UART, Ethernet, GPIO, SPI (+ flash SPI), SDIO (com um adaptador para um emulador de cartão SD), I2C, USB 2.0 OTG, PCIe, LVDS, RS232 CMOS, interruptores para comutação de energia e lógica teclas para ativação, por exemplo, botões.
O dispositivo possui o conjunto de interfaces mais comumente usado, além de um FPGA para a implementação de itens não padronizados. Como o sistema é projetado em um complexo, a ausência de conflitos mútuos é garantida. E as interfaces passarão de projeto para projeto em conjunto com o complexo, sem a necessidade de comprar algo adicional.
UPD: é assim que uma placa externa com conectores de interface Redd se parece. Ele "gruda" no conector no painel frontal e permite o uso de interfaces padrão. Embora uma variante também seja possível, mostrada em outras fotos, sem placa.
O equipamento desenvolvido costuma ser impossível de testar constantemente em condições de combate. Um helicóptero paga apenas 50 euros pelo apoio de expedição para decolagem e pouso. Dirigir um carro o tempo todo não é realista. Os navios nem sempre estão no mar. Em geral, precisamos de emuladores.
Como o sistema se comunica com o mundo exterior? Via sensores conectados a vários barramentos. Bem, os sinais para os atuadores também são emitidos nos ônibus. A atual gama de pneus é bastante ampla. Pode ser CAN, UART (na versão CMOS, RS232, RS485), Ethernet, MODBUS (através do mesmo UART ou Ethernet), linhas digitais com níveis diferentes e assim por diante, etc.
Uma solução típica é fazer emuladores de sensores e atuadores conectando-os aos barramentos. O equipamento em desenvolvimento considerará que ele recebe informações reais e o desenvolvedor imitará vários cenários de trabalho real, depurando algoritmos de trabalho. Obviamente, para cada projeto, você pode comprar controladores de várias interfaces e conectá-los.
Ou você pode conectar o Redd ao invés desses sensores e artistas, escrever simuladores de seu trabalho (ou seja, eles, ou seja, simulamos o ambiente externo) e, em seguida, depurar o dispositivo em desenvolvimento que pensa que está no carro ou em outro lugar, e fazemos lógica de destino de depuração. E os testadores por esse mecanismo poderão verificar situações limítrofes e até deliberadamente errôneas que são muito difíceis ou completamente impossíveis de reproduzir em testes comuns.
A parte do servidor do complexo está localizada diretamente no terminal. O desenvolvedor através da Web pode ver quais dispositivos e a que horas estão disponíveis para ele. Pode agendá-los em um calendário para que ele receba acesso automaticamente. Ele se conecta através do protocolo ssh ao terminal e, com ele, ao depurador e ao gerenciamento de emuladores de dispositivos. Além disso, o modo de operação do Redd pode ser não apenas multiusuário, mas também com a conexão simultânea de vários dispositivos.
Assim, o Redd permite organizar o acesso remoto de desenvolvedores internos ou externos a um dispositivo (ou um grupo de dispositivos, é possível conectar vários dispositivos a um terminal), planejar e gerenciar o acesso ao longo do tempo, sem movimento físico.
Um bônus adicional - o Redd também pode ser usado para demonstrar o produto a clientes externos e clientes sem uma transferência real. Ou para organizar a programação de dispositivos de ensino à distância, o que pode ser interessante para fabricantes de microprocessadores ou instituições de ensino.
O que agora
Agora estamos finalizando o desenvolvimento da primeira versão, que será lançada no início de março e já está
disponível para pré-venda (é claro, em termos preferenciais).
O principal objetivo deste artigo (exceto para publicidade) é coletar feedback.
Escreva se você não concorda que há problemas descritos no artigo ou pode nomear os problemas que esqueci.
Talvez você conheça uma solução que não encontramos, ou resolva esses problemas à sua maneira.
Ou eles estão prontos para nos apoiar com uma palavra gentil (ou talvez não apenas) no desenvolvimento de produtos.
Ficarei feliz em comentar.