Temos um dispositivo no qual estamos pensando em fazer uma atualização de software em um microcontrolador bare metal. A nova imagem seria programada em todos os produtos futuros.
Se eu fosse trocar um componente no dispositivo, precisaria preencher um pedido de alteração de engenharia.
Existe um procedimento equivalente da indústria ao trocar de software?
Respostas:
Eu ainda chamaria de ECO.
Se o firmware estiver programado no micro na fábrica, esse firmware e sua versão específica devem ser um item de linha na BOM.
Alterar o firmware significa alterar a lista técnica.
A alteração da lista técnica requer um ECO.
Depois disso, uma atualização de campo do firmware deve seguir um processo semelhante ao que seria seguido se um mod para o hardware fosse necessário para uma unidade no campo.
Portanto, se você chama isso de ECO, também é um ECO.
fonte
Normalmente, uma alteração de software é chamada de Patch ou (Atualização de software). E até onde eu sei (dependendo da empresa), os procedimentos são chamados de Patch ou Procedimento de atualização de software.
No entanto, na maioria dos casos, as atualizações de software não são mais do que executar um aplicativo especial que cuida da instalação e todas as conversões necessárias etc fazem parte do patch.
Portanto, diferentemente da troca eletrônica de peças, nenhum software existente atualmente normalmente precisa ser desinstalado ou alterado, porque faz parte do próprio software de correção.
Além disso, se houver restrições ou condições sobre quando a atualização do patch / software pode ou não pode ser instalada, ela será verificada no próprio patch e será instalada somente quando for válida para instalação (ou pelo menos, deve funcionar dessa maneira )
Portanto, em princípio, a atualização do patch / software faz muitas coisas, como (possivelmente não concluída):
fonte
Os termos que eu normalmente uso são Solicitação de mudança para itens que precisam ser alterados devido a requisitos modificados e Relatório de problemas para itens que precisam ser alterados devido a erros.
Eles são coletados e agendados para ciclos de atualização específicos. Se um ciclo é apenas interno, é chamado de Marco , se for implantado nos clientes, é chamado de Liberação .
Uma linha de tempo típica possui alguns marcos antes do lançamento, chamada Release Candidate, que passa por testes extensivos, e quaisquer erros encontrados geram outros Relatórios de Problemas que são novamente agendados para o próximo marco, se eles forem importantes o suficiente, ou para uma versão posterior, se não for.
Também é possível criar uma agência que atenda apenas PRs específicos em resposta a reclamações de clientes, com um release separado que não tenha mais alterações, na esperança de que menos erros sejam introduzidos aqui. Isso geralmente é feito apenas se o esforço para atualizações for baixo o suficiente (por exemplo, porque as atualizações podem ser instaladas simplesmente conectando um pendrive com um arquivo com um determinado nome).
fonte
Resposta curta: Está embutido no sistema de versão do software.
Resposta longa:
O software tende a mudar muito mais rapidamente que o hardware. Normalmente, o software usa algum tipo de sistema de controle de versão (VCS), como o popular Git. A maioria das empresas de software com as quais trabalhei usa um VCS para rastrear alterações no software, com cada confirmação explicando o raciocínio por trás da alteração. Alguns também usam um rastreador de problemas, que rastreia bugs, melhorias e outros conhecidos. Geralmente, existe um processo em que o desenvolvimento acontece em uma ramificação, e esse desenvolvimento é testado antes de ser mesclado em uma ramificação "principal" (liberação). Isso tende a ser muito mais eficiente para a alta frequência de alterações no desenvolvimento de software versus o ritmo mais lento do hardware. A implementação e o processo específicos disso variam de empresa para empresa e geralmente são influenciados por um padrão para fins de controle de qualidade (ISO9001, AS9100D, etc.).
Um exemplo:
Você decide fazer uma alteração.
Você cria um problema no rastreador de problemas.
fonte
Em uma configuração de setor executada corretamente, o firmware a ser inserido no micro é uma parte e possui um número de peça para esse executável específico (arquivo hexadecimal ou qualquer outro). Se você deseja alterar o firmware, é uma alteração na lista técnica (lista de materiais). E isso precisa de um ECO da mesma maneira como se você quisesse substituir um chip.
É realmente tão simples assim.
Há um corolário nisso. Se o seu firmware não possui um número de peça e não está listado na BOM e, portanto, não é controlado, é provável que seu processo de qualidade precise melhorar. Se você deve estar em conformidade com a ISO-9001 ou algo semelhante, é uma lacuna definitiva no seu processo que precisa ser corrigida.
fonte
As atualizações de software são chamadas de patches ou são o que são "atualizações de software". Eu sempre pergunto aos engenheiros de software se a unidade está atualizada "para a versão mais recente".
Idealmente, o controle de versão é "assinado" pelas partes interessadas e testado antes de ser lançado na produção, mas na maioria das vezes, na maioria dos lugares, essa prática ocorre apenas na maioria das vezes.
fonte