Was ist das Softwareäquivalent eines Änderungsauftrags?

Wir haben ein Gerät, auf dem wir erwägen, ein Software-Update auf einem Bare-Metal-Mikrocontroller durchzuführen. Das neue Image würde für alle zukünftigen Produkte programmiert.

Wenn ich eine Komponente auf dem Gerät ändern würde, müsste ich einen Änderungsauftrag ausfüllen.

Gibt es ein gleichwertiges Branchenverfahren für den Softwarewechsel?

Ich würde es immer noch als ECO bezeichnen.

Wenn die Firmware werkseitig im Micro programmiert ist, sollte diese Firmware und ihre spezifische Version eine Position in der Stückliste sein.
Das Ändern der Firmware bedeutet das Ändern der Stückliste.
Das Ändern der Stückliste erfordert eine ECO.

Darauf folgend sollte ein Feld-Update der Firmware einem ähnlichen Prozess folgen, wie er durchgeführt würde, wenn eine Modifikation der Hardware für ein Gerät im Feld erforderlich wäre.
Wenn Sie das also eine ECO nennen, dann ist dies auch eine ECO.

Normalerweise wird eine Softwareänderung als Patch oder (Software-Update) bezeichnet. Soweit mir bekannt ist (je nach Unternehmen), werden die Verfahren als Patch- oder Software-Update-Verfahren bezeichnet.

In den meisten Fällen sind Software-Updates jedoch nur das Ausführen einer speziellen Anwendung, die sich um die Installation kümmert, und alle erforderlichen Konvertierungen usw. sind Teil des Patches.

Im Gegensatz zum elektronischen Austausch von Teilen muss daher normalerweise keine vorhandene Software deinstalliert oder geändert werden, da sie Teil der Patch-Software selbst ist.

Falls Einschränkungen oder Bedingungen bestehen, wann das Patch / Software-Update installiert werden kann oder nicht, wird es im Patch selbst überprüft und nur installiert, wenn es für die Installation gültig ist (oder zumindest sollte es so funktionieren) ).

Das Patch / Software-Update macht also im Prinzip eine Menge Dinge, wie (möglicherweise nicht vollständig):

• Überprüfen Sie, ob der Patch / das Software-Update installiert werden kann (z. B. Betriebssystemversionen, aktuelle installierte Version usw.).
• Wenn nicht, wird eine Meldung angezeigt und der Patch / das Update wird angehalten.
• Wenn es installiert werden kann, werden die zu konvertierenden Dateien erstellt (dies ist manchmal Teil der Hauptanwendung, die gepatcht / aktualisiert werden soll).
• Neue Dateien werden aktualisiert oder zu der Anwendung hinzugefügt, die aktualisiert / gepatcht werden soll.
• Versionshinweise werden angezeigt (optional).
• Die Anwendung wird (optional) gestartet.

Die Begriffe, die ich normalerweise verwende, lauten Änderungsanforderung für Dinge, die aufgrund geänderter Anforderungen geändert werden müssen, und Problembericht für Dinge, die aufgrund von Fehlern geändert werden müssen.

Diese werden gesammelt und dann für bestimmte Aktualisierungszyklen geplant. Wenn ein Zyklus nur intern ist, wird er als Meilenstein bezeichnet . Wenn er für Kunden bereitgestellt wird, wird er als Release bezeichnet .

Ein typischer Zeitplan hat einige Meilensteine ​​vor der Veröffentlichung, Release Candidate genannt , die ausgiebig getestet werden, und alle dort gefundenen Fehler generieren weitere Problemberichte, die entweder für den nächsten Meilenstein erneut geplant werden, wenn sie wichtig genug sind, oder für eine spätere Veröffentlichung, wenn nicht.

Es ist auch möglich, eine Filiale zu erstellen , die nur bestimmte PRs als Reaktion auf Kundenbeschwerden adressiert, mit einer separaten Version, die keine weiteren Änderungen enthält, in der Hoffnung, dass hier weniger Fehler eingeführt werden. Dies geschieht in der Regel nur, wenn der Aufwand für Updates gering genug ist (z. B. weil Updates einfach durch Einstecken eines USB-Sticks mit einer Datei mit einem bestimmten Namen installiert werden können).

Kurze Antwort: Es ist in das Software-Versionssystem integriert.

Lange Antwort:

Software ändert sich tendenziell viel schneller als Hardware. Normalerweise verwendet Software eine Art Versionskontrollsystem (VCS), wie das beliebte Git. Die meisten Softwareunternehmen, mit denen ich zusammengearbeitet habe, verwenden ein VCS, um Änderungen an der Software nachzuverfolgen, wobei jedes Commit die Gründe für die Änderung erläutert. Einige verwenden auch einen Issue-Tracker, der bekannte Fehler, Verbesserungen und ähnliches nachverfolgt. Normalerweise gibt es einen Prozess, bei dem die Entwicklung auf einem Zweig stattfindet. Anschließend wird diese Entwicklung getestet, bevor sie zu einem "Haupt" -Zweig (Release) zusammengeführt wird. Dies ist in der Regel effizienter für die hohe Häufigkeit von Änderungen in der Softwareentwicklung im Vergleich zum langsameren Tempo in der Hardware. Die spezifische Implementierung und der Prozess hierfür variieren von Unternehmen zu Unternehmen und werden häufig von einem Standard für QS-Zwecke (ISO9001, AS9100D usw.) beeinflusst.

Ein Beispiel:

1. Sie entscheiden sich für eine Änderung.

2. Sie erstellen ein Problem im Issue Tracker.

3. Sie erstellen eine Zweigstelle, um das Problem zu beheben.
4. Sie nehmen einige Softwareänderungen vor.
5. Sie haben Ihre Änderungen gemäß den Unternehmensrichtlinien einer Peer-Review unterzogen
6. Sie geben eine Pull-Anforderung aus und führen sie in den Dev-Zweig zurück.
7. Sie schließen das Problem.

In einer ordnungsgemäß ausgeführten Industrieumgebung ist die Firmware, die in das Mikro geflasht werden soll, selbst ein Teil und hat eine Teilenummer für die jeweilige ausführbare Datei (Hex-Datei oder was auch immer). Wenn Sie die Firmware ändern möchten, handelt es sich um eine Änderung der Stückliste. Und das braucht eine ECO genauso, als wollten Sie einen Chip ersetzen.

Es ist wirklich so einfach.

Das hat eine Konsequenz. Wenn die Firmware nicht nicht eine Teilenummer haben und ist nicht in der Stückliste aufgeführt und daher wird nicht kontrolliert, dann wahrscheinlich den Qualitätsprozess muss verbessert werden . Wenn Sie ISO-9001 oder ähnliches erfüllen sollen, ist dies eine definitive Lücke in Ihrem Prozess, die behoben werden muss.

Software-Updates werden als Patches oder als "Software-Updates" bezeichnet. Ich frage immer die Software-Ingenieure, ob das Gerät "auf die neueste Version" aktualisiert wurde.

Im Idealfall wird die Versionierung von den Beteiligten "abgezeichnet" und getestet, bevor sie für die Produktion freigegeben wird. Meistens geschieht dies jedoch nur in den meisten Fällen.