我仍然称它为ECO。

如果固件在工厂中被编程到微控制器中，那么该固件及其特定版本应该是 BOM 上的一个行项目。
更改固件意味着更改 BOM。
更改 BOM 需要 ECO。

此后，固件的现场更新应遵循与现场单元需要对硬件进行改装时所遵循的过程类似的过程。
因此，如果您称其为 ECO，那么这也是 ECO。

通常，软件更改称为补丁或（软件更新）。据我所知（取决于公司），这些程序称为补丁程序或软件更新程序。

但是，在大多数情况下，软件更新只不过是运行一个负责安装的特殊应用程序，所有需要的转换等都是补丁的一部分。

因此，与电子零件交换不同，当前现有的软件通常不需要卸载或更改，因为它是补丁软件本身的一部分。

此外，如果补丁/软件更新何时可以安装或不能安装有限制或条件，它将在补丁本身中进行检查，并且仅在安装有效时安装（或至少应该以这种方式工作） ）。

所以原则上补丁/软件更新做了很多事情，比如（可能不完整）：

• 检查是否可以安装补丁/软件更新（例如操作系统版本、安装的当前版本等）
• 如果没有，将显示一条消息并停止补丁/更新。
• 如果可以安装，将完成需要转换的文件（这有时是要修补/更新的主应用程序的一部分）。
• 新文件被更新或添加到要更新/修补的应用程序中。
• 显示发行说明（可选）。
• 应用程序已启动（可选）。

我通常使用的术语是Change Request表示由于修改需求而需要更改的内容，而Problem Report表示由于错误而需要更改的内容。

这些被收集，然后安排特定的更新周期。如果一个周期仅是内部的，则称为Milestone，如果将其部署给客户，则称为Release。

一个典型的时间线在发布之前有几个里程碑，称为候选发布，经过广泛的测试，并且在那里发现的任何错误都会生成进一步的问题报告，如果它们足够重要，它们会再次安排到下一个里程碑，或者如果不重要，则安排在以后的发布中。

也可以创建一个仅针对特定 PR 以响应客户投诉的分支，并单独发布一个没有进一步更改的版本，希望这里引入的错误更少。这通常仅在更新工作量足够低的情况下进行（例如，因为只需插入带有特定名称文件的 USB 记忆棒即可安装更新）。

简短的回答：它内置在软件版本控制系统中。

长答案：

软件的变化往往比硬件快得多。通常软件使用某种版本控制系统 (VCS)，例如流行的 Git。我合作过的大多数软件公司都使用 VCS 来跟踪软件的更改，每次提交都会解释更改背后的原因。有些人还使用问题跟踪器，它跟踪已知的错误、改进等。通常有一个流程，在一个分支上进行开发，然后在合并到“主”（发布）分支之前对该开发进行测试。对于软件开发中的高频率变化与硬件中较慢的速度相比，这往往更有效。具体实施和流程因公司而异，并且经常受到用于 QA 目的的标准（ISO9001、AS9100D 等）的影响。

一个例子：

1. 你决定做出改变。

2. 您在问题跟踪器中创建问题。

3. 您创建一个分支来解决该问题。
4. 您进行了一些软件更改。
5. 根据公司政策，您的更改经过同行评审
6. 您发出拉取请求并合并回 dev 分支。
7. 你关闭问题。