What is the software equivalent of an engineering change order?

I'd still call it an ECO.

If the firmware is programmed into the micro in the factory, then that firmware and its specific version should be a line item on the BOM.
Changing the firmware means changing the BOM.
Changing the BOM requires an ECO.

Following on from that, a field update of the firmware should follow a similar process to that which would be followed if a mod to the hardware were required to a unit in the field.
So if you call that an ECO, then this is also an ECO.

Normally a software change is called a Patch or a (Software Update). And as far as I know (depending on the company) the procedures are called Patch or Software Update Procedure.

However, in most cases software updates are not more than running a special application that takes care of the installation and all needed conversions etc are part of the patch.

So unlike electronic part exchange, no current existing software normally has to be uninstalled or changed, because it is part of the patch software itself.

Also, in case there are restrictions or conditions on when the patch/software update can or cannot be installed, it will be checked in the patch itself and will only install when it is valid to install (or at least, it should work that way).

So in principle the patch/software update does a lot of things, like (possibly not complete):

• Check if the patch/software update can be installed (e.g. Operating system versions, current version installed etc.)
• If not, a message will be shown and the patch/update stops.
• If it can be installed, files which need to be converted will be done (this sometimes is part of the main application to be patched/updated).
• New files are updated or added to the application to be updated/patched.
• Release notes are shown (optionally).
• The application is started (optionally).

The terms I normally use are Change Request for things that need to be changed due to modified requirements, and Problem Report for things that need to be changed due to errors.

These are collected, and then scheduled for specific update cycles. If a cycle is internal only, it is called a Milestone, if it is deployed to customers, it is called a Release.

A typical timeline has a few milestones before the release, called Release Candidate that undergoes extensive testing, and any errors found there generate further Problem Reports that are again scheduled for either the next milestone if they are important enough, or a later release if not.

It is also possible to create a Branch that only addresses specific PRs in response to customer complaints, with a separate release that has no further changes, in the hope that fewer errors are introduced here. This is usually only done if the effort for updates is low enough (e.g. because updates can be installed simply by plugging in an USB stick with a file with a certain name on it).