14

We have a device on which we are considering doing a software update on a bare metal microcontroller. The new image would be programmed on all future products.

If I was to change a component on the device, I would need to fill in an engineering change order.

Is there an equivalent industry procedure when changing software?

Peter Mortensen
  • 1,679
  • 3
  • 17
  • 23
SeanJ
  • 907
  • 1
  • 7
  • 20
  • 1
    It depends. In the medical devices world FDA guidelines calls it ECR and ECO so we call it that way too. But in reality, especially for less regulated industries or with more "agile" management, there isn't a concept of ECO but ECR. When CR is submitted, the work would start. CO is usually given implicitly when "submit approve" is granted to a change. Things attached to CO such as risk analysis is either optional or non-existent, too. – user3528438 Nov 09 '17 at 23:41
  • I always called it an "escape". – Hot Licks Nov 10 '17 at 03:51

6 Answers6

29

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.

psmears
  • 704
  • 4
  • 7
brhans
  • 14,723
  • 3
  • 35
  • 51
  • 1
    Yup this is how my old company did it. Firmware versions were just another item on the BOM for factory programming. We were able to field update our software, so we would have releases for bug fixes/custom jobs and those would be assigned a part number as well (just not called out on the BOM). – shenles Nov 09 '17 at 18:13
  • This answer the question if the project in question is a product with software as a component. But what if the project itself is software? – user3528438 Nov 09 '17 at 23:42
  • 2
    @user3528438 - then the question would be off-topic here on the electrical engineering SE wouldn't it. – brhans Nov 10 '17 at 00:46
6

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).
Michel Keijzers
  • 13,987
  • 19
  • 75
  • 143
  • @MichaelKeijzers The software of which I'm speaking is the firmware being programmed onto a bare metal microcontroller. It means that all future parts will have the new software which is different to a patch or OTA upgrade. Does the above still apply, (I've edited the question based on your feedback) – SeanJ Nov 09 '17 at 10:02
  • 1
    I think it still applies. However, the upgraded firmware is part of the patch/software upgrade I describe. So in the companies I worked, the patches/upgrade created do not only the chips firmware update (mostly via controller software), but also the above steps are performed. – Michel Keijzers Nov 09 '17 at 10:07
6

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).

Simon Richter
  • 12,618
  • 1
  • 25
  • 52
4

Short answer: It is built into the software versioning system.

Long answer:

Software tends to change much more rapidly than hardware. Usually software uses some sort of version control system (VCS), like the popular Git. Most software companies I've worked with use a VCS to track changes to the software, with each commit explaining the reasoning behind the change. Some also use an issue tracker, which tracks known bugs, improvements, and such. Usually there is a process in place where development happens on one branch, then that development is tested prior to being merged into a "main" (release) branch. This tends to be much more efficient for the high frequency of changes in software development vs the slower tempo in hardware. The specific implementation and process of this varies from company to company, and is often influenced by a standard for QA purposes(ISO9001, AS9100D, etc.).

An example:

  1. You decide to make a change.

  2. You create an issue in the issue tracker.

  3. You create a branch to address the issue.
  4. You make some software changes.
  5. You have your changes peer reviewed per company policy
  6. You issue a pull request and merge back into the dev branch.
  7. You close the issue.
ScarySpider
  • 141
  • 2
  • 3
    This answers the wrong question. The OPs question is in the first line of your example: what is the name of the process of "deciding to make a change" – whatsisname Nov 10 '17 at 00:09
4

In a properly-run industry setting, the firmware to be flashed into the micro is itself a part and has a part number for that specific executable (hex file or whatever). If you want to change the firmware, it's a change to the BOM (bill of materials). And that needs an ECO in the same way as if you wanted to replace a chip.

It's really as simple as that.

There's a corollary to this. If your firmware does not have a part number and is not listed in the BOM and hence is not controlled, then your quality process probably needs improving. If you are supposed to be meeting ISO-9001 or something similar, this is a definite gap in your process which needs fixing.

Graham
  • 6,150
  • 13
  • 20
3

Software updates are called patches or they are what they are "software updates". I always ask the software engineers if the unit is updated "to the latest version".

Ideally versioning is "signed" off by stakeholders and tested before it is released into production, but more often than not at most places this practice only happens most of the time.

Voltage Spike
  • 82,181
  • 41
  • 84
  • 220