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


14

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?


1
Ça dépend. Dans le monde des dispositifs médicaux, les directives de la FDA l'appellent ECR et ECO, nous l'appelons ainsi également. Mais en réalité, surtout pour les industries moins réglementées ou avec une gestion plus "agile", il n'y a pas de concept ECO mais ECR. Lorsque CR est soumis, le travail commence. Le CO est généralement donné implicitement lorsque «soumettre approuver» est accordé à un changement. Les éléments liés au CO, tels que l'analyse des risques, sont également facultatifs ou inexistants.
user3528438

J'ai toujours appelé ça une "évasion".
Hot Licks

Réponses:


29

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.


1
Oui, c'est comme ça que mon ancienne entreprise le faisait. Les versions du micrologiciel n'étaient qu'un autre élément de la nomenclature pour la programmation en usine. Nous avons pu mettre à jour notre logiciel sur le terrain, nous aurions donc des versions pour les corrections de bugs / travaux personnalisés et ceux-ci se verraient également attribuer un numéro de pièce (tout simplement pas appelé sur la nomenclature).
shenles

Cela répond à la question si le projet en question est un produit avec un logiciel en tant que composant. Mais que se passe-t-il si le projet lui-même est un logiciel?
user3528438

2
@ user3528438 - alors la question serait hors sujet ici sur l'électrotechnique SE, n'est-ce pas?
brhans

6

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).

@MichaelKeijzers Le logiciel dont je parle est le firmware en cours de programmation sur un microcontrôleur en métal nu. Cela signifie que toutes les futures parties auront le nouveau logiciel qui est différent d'un patch ou d'une mise à niveau OTA. Est-ce que ce qui précède s'applique toujours (j'ai édité la question en fonction de vos commentaires)
SeanJ

1
Je pense que cela s'applique toujours. Cependant, le micrologiciel mis à niveau fait partie de la mise à niveau du correctif / logiciel que je décris. Ainsi, dans les entreprises où j'ai travaillé, les correctifs / mises à niveau créés ne font pas seulement la mise à jour du micrologiciel des puces (principalement via le logiciel du contrôleur), mais également les étapes ci-dessus sont effectuées.
Michel Keijzers

6

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).


4

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.

3
Cela répond à la mauvaise question. La question des PO se trouve dans la première ligne de votre exemple: quel est le nom du processus de "décision d'apporter un changement"
whatsisname

4

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.


3

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.