我們有一個正在考慮在裸機微控制器上進行軟件更新的設備。新映像將在以後的所有產品中編程。
如果要更改設備上的組件，則需要填寫工程更改單。
更改軟件時是否存在等效的行業程序？
我仍然稱其為ECO。
如果固件在工廠中已編程到微型計算機中，則該固件及其特定版本應該是BOM上的行項目。
更改固件意味著更改BOM。
更改BOM需要ECO。
此後，固件的現場更新應遵循與現場需要對硬件進行修改的過程類似的過程。
因此，如果您稱其為ECO，那麼這也是ECO。
通常，軟件更改稱為補丁或（軟件更新）。據我所知（取決於公司），該過程稱為補丁或軟件更新過程。
但是，在大多數情況下，軟件更新只不過是運行特殊的應用程序來管理安裝，並且所有需要的轉換等都是補丁的一部分。
因此，與電子零件交換不同，由於補丁程序本身是補丁軟件的一部分，因此通常不必卸載或更改當前的現有軟件。
此外，如果在何時可以安裝補丁/軟件更新存在限製或條件，則將在補丁本身中對其進行檢查，並且僅在有效安裝時才安裝（或至少應在安裝時）。這樣工作。
因此，原則上，補丁程序/軟件更新會完成很多事情，例如（可能不完整）：
我通常使用的術語是變更請求，用於因修改後的需求而需要更改的內容，以及問題報告，用於因錯誤而需要更改的內容
收集這些信息，然後計劃進行特定的更新周期。如果週期僅是內部周期，則稱為里程碑；如果將周期部署到客戶，則稱為 Release 。
一個典型的時間表在發布之前有幾個里程碑，稱為 Release Candidate ，該里程碑經過了廣泛的測試，發現的任何錯誤都會產生進一步的問題報告，如果有的話，它們會再次排定在下一個里程碑足夠重要，如果不是，請稍後發布。
還可以創建一個分支，該分支僅針對特定的PR來響應客戶的投訴，並發布一個單獨的版本，沒有進一步的更改，希望此處引入的錯誤更少。通常只有在更新工作量較低的情況下才能執行此操作（例如，因為只需插入帶有特定名稱的文件的USB記憶棒即可安裝更新）。
簡短的答案：它內置在軟件版本控制系統中。
長答案：
軟件的變化趨勢往往比硬件變化快得多。通常，軟件使用某種版本控制系統（VCS），例如流行的Git。與我合作過的大多數軟件公司都使用VCS來跟踪軟件的更改，每次提交都說明了更改背後的原因。有些還使用問題跟踪器，該跟踪器跟踪已知的錯誤，改進等。通常，有一個過程是在一個分支上進行開發，然後在將該開發合併到“主”（發布）分支之前對其進行測試。對於軟件開發中的高頻變化，與較慢的硬件速度相比，這往往效率更高。各個公司的具體實施方式和過程各不相同，並且通常受質量保證標準（ISO9001，AS9100D等）的影響。
一個例子：
您決定進行更改。
您可以在問題跟踪器中創建問題。
在正常運行的行業環境中，要閃存到微型計算機中的固件本身就是一部分，並且具有該特定可執行文件（十六進製文件或任何其他文件）的部件號。如果要更改固件，那就是BOM（物料清單）的更改。這就需要一種ECO，就像您要更換芯片一樣。
就這麼簡單。
這是必然的。如果您的固件中沒有 not 且沒有零件編號，並且未在BOM表中列出 not ，因此受 not 控制，那麼您的質量流程可能需要改進。如果您應該達到ISO-9001或類似標準，則這是您過程中的一個明顯空白，需要修復。
軟件更新稱為補丁程序，或者它們是“軟件更新”。我總是問軟件工程師，是否將設備更新為“最新版本”。
理想情況下，版本控制由利益相關者“簽名”，並在發佈到生產環境之前進行測試，但是在大多數情況下，這種做法通常只會在大多數時間發生。