工程变更单的软件等同于什么？

我们有一台正在考虑在裸机微控制器上进行软件更新的设备。新映像将在以后的所有产品中编程。

如果要更改设备上的组件，则需要填写工程更改单。

更换软件时是否有等效的行业程序？

我仍然称其为ECO。

如果在工厂将固件编程到微型计算机中，则该固件及其特定版本应该是BOM上的行项目。
更改固件意味着更改BOM。
更改BOM需要ECO。

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

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

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

因此，与电子零件交换不同，由于修补软件本身是现有软件的一部分，因此通常无需卸载或更改现有软件。

另外，如果在何时可以安装补丁程序/软件更新存在限制或条件，则将在补丁程序本身中对其进行检查，并且仅在有效安装时才安装（或者至少应该以这种方式工作） ）。

因此，原则上补丁/软件更新会完成很多事情，例如（可能不完整）：

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

我通常使用的术语是针对因修改后的需求而需要更改的事物的“ 更改请求 ”和“ 问题报告”针对因错误而需要更改的内容的。

收集这些，然后计划进行特定的更新周期。如果周期仅是内部周期，则称为里程碑；如果将周期部署到客户，则称为发布。。

典型的时间表在发布之前有几个里程碑，即经过广泛测试的候选发布，并且在那里发现的任何错误都会产生进一步的问题报告，如果它们足够重要，则可以再次计划下一个里程碑，如果不是的话，可以安排更高版本。

还可以创建一个仅针对特定PR来响应客户投诉的分支，并使用一个单独的版本进行进一步的更改，以期在此处引入更少的错误，以解决此问题。通常只有在更新工作量足够低的情况下才能执行此操作（例如，因为可以通过插入带有特定名称的文件的USB记忆棒来安装更新）。

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

长答案：

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

一个例子：

1. 您决定进行更改。

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

3. 您创建一个分支来解决该问题。
4. 您进行一些软件更改。
5. 您已根据公司政策对变更同事进行审查
6. 您发出拉取请求，然后合并回dev分支。
7. 您关闭问题。

在正常运行的行业环境中，要刷新到微型计算机中的固件本身就是其中一部分，并且具有该特定可执行文件（十六进制文件或其他文件）的部件号。如果要更改固件，那就是BOM（物料清单）的更改。这就需要一种ECO，就像您要更换芯片一样。

就这么简单。

这是必然的。如果您的固件并没有有零件编号，并没有在BOM中列出，因此是不受控的，那么你的质量过程大概需要改进。如果您应该达到ISO-9001或类似标准，则这是您过程中的一个明显空白，需要修复。

软件更新称为补丁程序，或者它们是“软件更新”。我总是问软件工程师，是否将设备更新为“最新版本”。

理想情况下，版本控制应由利益相关者“签名”并在发布到生产环境之前进行测试，但是这种做法通常在大多数时间仅在大多数地方发生。