About ODM Firmware
After a firmware is released from the vendor, new firmware may need to be tested and validated then either approved or rejected for roll out. The system provides the needed functionality to support validating and updating firmware versions as needed.
Associating Firmware and Firmware Versions to Assets
In most business processes, firmware and firmware version is entered as part of the manufacturer settings when assets are created. This information appears in the Settings section on the asset. Also during asset creation, a basic business process would associate an asset specification to the asset to keep track of detailed manufacturer information which might also include the firmware. Attached, as a child to that specification, would be another specification that indicates the firmware versions that are available.
As firmware versions change the child specification is updated with new versions. These versions can then be tested and accepted or rejected using the lifecycle functionality on the specification.
Next, field activities can be created directly from the Field Activity portal or by using the Activity Generator to update the firmware version on the assets that are associated with those specifications. For example, your business process might require that you create an Asset Criteria Generator type record to create a list of assets based on firmware as the selection attribute. The system would then apply the updates from the record to any assets that meet that criteria (for example, that have that firmware type or version).
Firmware Management
You can use the system to manage firmware in the following ways:
Create firmware groupings: Record firmware versions into groupings or "families" on specifications so that related versions can be easily managed together.
Add firmware to assets: Use peer specifications to associate assets to these firmware groups.
Review firmware: Review firmware distribution and status in the Firmware Deployment and Firmware Version Dispositions zones on specifications.
Document firmware: Manage related release notes or manufacturer information by creating attachments directly on the specification.
Test firmware: Track testing and roll out of new firmware versions including the ability to approve or reject firmware version deployments.
Update firmware: Create field activities to update firmware versions on assets.
Reject firmware versions: After testing, set the firmware version to an inactive status to indicate that the firmware version cannot be used for assets.
The Configurations portal manages asset to component to firmware configurations that determine which versions are valid for which assets. Configuration Reports can be used to obtain details about the configurations and verify that the correct versions are in use.
Firmware on Specifications
The Firmware Deployment section on specifications provides statistics on the number of assets that are on each version of the firmware that is applicable to the specification. Click the pie chart for a version to see the number of assets on that versions grouped by the asset state.
The Firmware Versions section lists the firmware that has been added using the specification. Use the Add Firmware Version link in the zone to add a new version. Click on one of the listed versions to open a screen with more details about the firmware. This screen can also be used to add attachments for the specific firmware version. For example, you might attach the release notes that were delivered with the firmware release. On this screen, the Firmware Version Dispositions section lists the assets that use the firmware version indicated, if any.
Firmware Version Lifecycle
Statuses for firmware version updates can be managed on the specification by selecting the actions in the Record Actions section. Valid statuses include:
Active Statuses
created
under testing
approved
Intermittent Statuses
deprecated
quarantined
Inactive Statuses
rejected
obsolete
If the firmware version is in an intermittent status, assets or components can reference that version. In general, these statuses are for documentation purposes. for example, an organization might use the Deprecated status to indicate that they do not want to roll out new meters on that version any longer, however, existing meters that are on that version are still valid. No assets or components can have the version associated if the version is in one of the inactive statuses.