Quel est l'équivalent logiciel d'un ordre de modification technique?

Nous avons un appareil sur lequel nous envisageons de faire une mise à jour logicielle sur un microcontrôleur en métal nu. La nouvelle image serait programmée sur tous les futurs produits.

Si je devais changer un composant sur l'appareil, je devrais remplir un ordre de modification technique.

Existe-t-il une procédure industrielle équivalente lors du changement de logiciel?

Je l'appellerais toujours un ECO.

Si le micrologiciel est programmé dans le micro en usine, ce micrologiciel et sa version spécifique doivent être un élément de ligne sur la nomenclature.
Changer le firmware signifie changer la nomenclature.
La modification de la nomenclature nécessite un ECO.

Suite à cela, une mise à jour sur le terrain du firmware devrait suivre un processus similaire à celui qui serait suivi si un mod du matériel était requis pour une unité sur le terrain.
Donc, si vous appelez cela un ECO, alors c'est aussi un ECO.

Normalement, un changement de logiciel est appelé Patch ou (Mise à jour de logiciel). Et pour autant que je sache (selon la société), les procédures sont appelées Patch ou Procédure de mise à jour logicielle.

Cependant, dans la plupart des cas, les mises à jour logicielles ne sont pas plus que l'exécution d'une application spéciale qui prend en charge l'installation et toutes les conversions nécessaires, etc. font partie du correctif.

Ainsi, contrairement à l'échange de pièces électroniques, aucun logiciel existant actuel ne doit normalement être désinstallé ou modifié, car il fait partie du logiciel de correction lui-même.

De plus, dans le cas où il existe des restrictions ou des conditions sur le moment où le correctif / la mise à jour logicielle peut ou ne peut pas être installé, il sera vérifié dans le correctif lui-même et ne sera installé que s'il est valide pour l'installation (ou du moins, il devrait fonctionner de cette façon ).

Donc, en principe, la mise à jour du correctif / logiciel fait beaucoup de choses, comme (peut-être pas complète):

• Vérifiez si le correctif / la mise à jour logicielle peut être installé (par exemple, versions du système d'exploitation, version actuelle installée, etc.)
• Sinon, un message sera affiché et le patch / la mise à jour s'arrêtera.
• S'il peut être installé, les fichiers à convertir seront effectués (cela fait parfois partie de l'application principale à patcher / mettre à jour).
• De nouveaux fichiers sont mis à jour ou ajoutés à l'application pour être mis à jour / corrigé.
• Les notes de version sont affichées (en option).
• L'application est lancée (éventuellement).

Les termes que j'utilise normalement sont Demande de changement pour les choses qui doivent être changées en raison d'exigences modifiées et Rapport de problème pour les choses qui doivent être changées en raison d'erreurs.

Ceux-ci sont collectés, puis planifiés pour des cycles de mise à jour spécifiques. Si un cycle est uniquement interne, il est appelé un jalon , s'il est déployé auprès des clients, il est appelé une version .

Une chronologie typique comporte quelques jalons avant la sortie, appelée Release Candidate qui subit des tests approfondis, et toutes les erreurs trouvées génèrent d'autres rapports de problèmes qui sont à nouveau planifiés pour le prochain jalon s'ils sont suffisamment importants, ou une version ultérieure dans le cas contraire.

Il est également possible de créer une succursale qui ne traite que des RP spécifiques en réponse aux plaintes des clients, avec une version distincte qui n'a pas d'autres modifications, dans l'espoir que moins d'erreurs soient introduites ici. Cela n'est généralement effectué que si l'effort de mise à jour est suffisamment faible (par exemple parce que les mises à jour peuvent être installées simplement en branchant une clé USB contenant un fichier portant un certain nom).

Réponse courte: il est intégré au système de gestion des versions du logiciel.

Longue réponse:

Le logiciel a tendance à changer beaucoup plus rapidement que le matériel. Habituellement, les logiciels utilisent une sorte de système de contrôle de version (VCS), comme le populaire Git. La plupart des éditeurs de logiciels avec lesquels j'ai travaillé utilisent un VCS pour suivre les modifications apportées au logiciel, chaque engagement expliquant le raisonnement derrière le changement. Certains utilisent également un outil de suivi des problèmes, qui suit les bogues connus, les améliorations, etc. Habituellement, il y a un processus en place où le développement se produit sur une branche, puis ce développement est testé avant d'être fusionné en une branche "principale" (version). Cela a tendance à être beaucoup plus efficace pour la fréquence élevée des changements dans le développement logiciel par rapport au rythme plus lent du matériel. La mise en œuvre et le processus spécifiques de ce processus varient d'une entreprise à l'autre et sont souvent influencés par une norme à des fins d'AQ (ISO9001, AS9100D, etc.).

Un exemple:

1. Vous décidez de faire un changement.

2. Vous créez un problème dans l'outil de suivi des problèmes.

3. Vous créez une branche pour résoudre le problème.
4. Vous apportez quelques modifications logicielles.
5. Vous avez vos modifications examinées par les pairs conformément à la politique de l'entreprise
6. Vous émettez une demande d'extraction et fusionnez à nouveau dans la branche de développement.
7. Vous fermez le problème.

Dans un environnement industriel correctement géré, le firmware à flasher dans le micro est lui-même une partie et possède un numéro de pièce pour cet exécutable spécifique (fichier hexadécimal ou autre). Si vous voulez changer le firmware, c'est un changement de nomenclature. Et cela nécessite un ECO de la même manière que si vous vouliez remplacer une puce.

C'est vraiment aussi simple que ça.

Il y a un corollaire à cela. Si votre micrologiciel n'a pas de numéro de pièce et n'est pas répertorié dans la nomenclature et n'est donc pas contrôlé, votre processus de qualité doit probablement être amélioré. Si vous êtes censé respecter la norme ISO-9001 ou quelque chose de similaire, il s'agit d'une lacune certaine dans votre processus qui doit être corrigée.

Les mises à jour logicielles sont appelées correctifs ou ce sont des «mises à jour logicielles». Je demande toujours aux ingénieurs logiciels si l'unité est mise à jour "vers la dernière version".

Idéalement, le contrôle de version est «validé» par les parties prenantes et testé avant sa mise en production, mais le plus souvent, dans la plupart des cas, cette pratique ne se produit que la plupart du temps.