NDT Instrument Software Changes: Keep a Reviewable Record

Identify the exact instrument and proposed change

Record the manufacturer, model, serial and current software or firmware identifiers available through the organization's approved process. Distinguish the main instrument software from an associated computer application, module or accessory version where those are separate. A note saying software updated cannot explain which part of the system changed.

Identify the proposed target version and the source of that information. Use the manufacturer's applicable release information and instructions for the actual model. Do not treat an online statement describing a release as proof that it is the latest or appropriate version for every instrument in the organization.

State why the change is proposed, such as a documented support need, a required capability or an approved maintenance action. Preserve the requester's reasoning without converting it into an automatic approval. The technical and information-technology responsibilities may differ, and the coordinator should make both visible where relevant.

Retrieve the applicable manufacturer information

Collect the release notes, instructions, compatibility information and relevant manual references that the authorized reviewer needs. Record their version or publication context where available. A generic product brochure may describe features without supplying the information needed to assess a specific change.

Manufacturer documentation can be version-specific. Evident's manuals library, for example, identifies software-version manuals for relevant instrument families. Use the actual applicable document rather than assuming that the newest generic manual describes the configuration currently in service. Evident manuals

Keep the source documents or stable references with the change record according to your process. If an instruction changes later, a reviewer may need to know which information supported the original decision. Avoid relying solely on a temporary download link or a remembered conversation with a supplier representative.

Map the affected configuration and workflow

Ask the technical owner which parts of the equipment configuration and workflow require consideration. These may include instrument settings, accessories, analysis software, report templates or customer file handover. The coordinator should record the identified dependencies without deciding that every software change affects every element.

Distinguish a proposed capability from an approved use. A release may add features, but their presence does not automatically authorize the organization to use them on a particular examination. Preserve the appropriate technical procedure and review references rather than advertising the new menu option as an approved inspection method.

If several instruments are involved, identify the exact population. A fleet-level request should not become an untracked series of local updates with different versions and dates. Keep each item's current and target configuration visible, along with any approved exclusions or staged implementation decisions.

Consider file and record compatibility explicitly

Identify whether the proposed change affects creation, opening, transfer or interpretation of equipment-generated files. Ask the responsible owner to assess the actual file types and downstream applications used by the organization. A file extension alone may not capture every compatibility issue, so retain the manufacturer's explanation and the defined review scope.

A documented manufacturer example illustrates why this matters: Evident states that MXU 5.11 for OmniScan X3 and X3 64 changed newly created data files from the ODAT format to the NDE format. That historical example is not a recommendation to install that version; it shows that a software event can have a record-handover consequence. Evident file-format information

Keep existing source data and any approved conversion output distinguishable. Do not overwrite historical files simply to make the archive look uniform. The responsible technical and data owners should define what must remain retrievable and how any transformed file is identified and verified.

Preserve the pre-change evidence through the approved process

Record the current version, relevant configuration references and the source files or settings the authorized process requires retaining. Do not improvise a backup method that the manufacturer or organization has not approved for the instrument. The coordinator can confirm that the required preservation action has an owner and completion reference.

Keep the preservation record separate from the change approval. A completed backup does not by itself authorize installation, and an approved change does not prove that the required records were preserved. Each dependency should have a clear outcome before the process moves to the next stage.

If a rollback or recovery arrangement is required, have the responsible technical owner define it. This guide does not assume that every instrument supports reversal to an earlier version. Record the actual available options and limits, rather than promising that a failed update can always be undone.

Plan the change window and equipment controls

Coordinate the timing with operations and the authorized people performing the change. Include the time required for the defined post-change review and evidence handover, not only the installation activity. An instrument should not be promised to a crew at the moment an installer expects to finish if the organization's return decision still remains.

Identify the status and physical administrative controls that apply during the work. The free tracker can summarize the current state, but it does not install firmware, lock equipment out of dispatch or run a validation sequence. Use the actual equipment-control process to communicate unavailability.

If the change is performed by a supplier during service, include the requirement in the service order and ask for the installed version and relevant work record on return. Do not assume that the supplier preserved the earlier configuration or performed your organization's required review unless that was actually agreed and evidenced.

Record what was actually changed

After the authorized work, capture the actual installed version and event date through the approved process. Compare them with the requested target. A planned version and a completed version can differ because the supplier revised its proposal or the change did not complete as expected.

Record who performed the activity and the supporting service or change reference. Preserve unexpected outcomes, warnings or deviations that the responsible owner needs to assess. The coordinator should not rewrite the record to match the original plan merely because that makes the file look cleaner.

If the work stops partway or leaves the current configuration uncertain, keep the appropriate restriction and escalation visible. A partially completed change is not the same as a successful update. Route the issue to the authorized technical or supplier support process without attempting undocumented recovery steps.

Support the defined post-change review

Have the technical owner identify the review or verification required for the actual change and intended use. The coordinator can assemble manufacturer information, performed-work evidence and the relevant configuration references. This article does not prescribe technical checks, acceptance limits or a universal recalibration requirement.

Record the result and authorization in a way that identifies the instrument and version reviewed. A general statement that the new software was tested elsewhere may not describe the specific item or configuration being released. The reviewer should determine the appropriate scope and retain its basis.

Keep the calibration due date separate. A software update date does not automatically restart an interval, and a current certificate does not automatically settle every question raised by the change. Update equipment dates or status only according to the actual authorized decisions and their supporting references.

A hypothetical supplier-installed update

A fictional company sends instrument EQ-135 for a service event and authorizes a specific software change after review. The supplier returns the instrument with a service report identifying a different installed version from the original request. The coordinator records the discrepancy and obtains the supplier's explanation rather than editing the request to match the return silently.

The technical owner reviews the actual version, applicable documentation and any effect on the organization's file handover. The equipment remains under the defined controls until the required decision is recorded. A separate calibration report is reviewed for its own scope and event; neither document is treated as a substitute for the other.

The final history identifies the before and after versions, supplier action, review reference and resulting state. This fictional example illustrates administrative control of a changed plan. It does not establish whether any particular software version is suitable for an NDT application.

Update the history and downstream references

Add the change event to the instrument history index and connect the relevant documents. Preserve the previous version record for historical interpretation. If a customer or internal process needs to know the version used on an earlier assignment, the current screen alone will not answer that question after an update.

Review affected manuals, configuration references and data-handover instructions through their responsible owners. Avoid leaving staff with an obsolete local document while the instrument uses a newer configuration. Equally, do not replace every historical instruction in the archive as though the new version had always been used.

The free NDT Connect tracker has no dedicated software-version history field or change-approval module. Use concise notes to point to the controlled change record where useful. Do not treat a note saying updated as a complete record of versions, evidence, review and authorization.

Learn from the change without creating a blanket rule

Review the actual difficulties: unclear supplier reporting, missing pre-change records, incompatible downstream files or delayed internal review. Improve the relevant handoff for the next event. A successful update on one item does not prove that every instrument, accessory combination or workflow can be changed under identical assumptions.

Keep future decisions tied to current manufacturer information and the organization's intended use. Security, support and technical needs can all matter, but their implications should be assessed by the appropriate owners. The coordinator should preserve the decision path rather than invent a universal always-update or never-update policy.

A useful software-change record explains what was proposed, what actually changed, what evidence was retained and who authorized the resulting state. That continuity helps the organization interpret both current equipment and historical data without confusing a version number with a complete technical approval.

Prepare a compatibility question sheet for the actual workflow

List the specific files and downstream tasks the organization needs to preserve across the proposed change. These may include opening historical data, using approved setup references, delivering files to a customer and reviewing data with an associated application. Ask the responsible technical and data owners to define the relevant questions rather than assuming that a new version affects every task in the same way.

For each question, identify the manufacturer information, authorized review or other evidence that will answer it. A release note may establish that a file format changed, while the organization's review establishes whether its actual handover workflow remains suitable. Keep those evidence roles distinct. The manufacturer description alone does not prove that every customer or legacy application can interpret the resulting files.

Use a fictional case in which the instrument's proposed software version creates a different output format from the one named in an existing customer handover agreement. The coordinator records the discrepancy and routes it to the technical and customer-contact owners before implementation. The response may involve an approved workflow or agreement change, but the coordinator should not simply rename file extensions or promise compatibility without evidence.

Preserve the original files used in any authorized review and identify derived or converted copies clearly. Record the actual version and configuration involved. A useful compatibility receipt explains which workflow was assessed and its limitations, not only that a sample file opened on one person's computer.

Manage a multi-instrument change as individual completed events

A fleet change plan should identify each instrument's starting configuration, approved target, implementation owner and required review. Keep exclusions and staged decisions visible. Instruments with the same model name may have different relevant configurations or assignment constraints, and the coordinator should not assume that one completed update settles every item in the group.

Track planned, performed and approved states separately. A supplier can complete installation on several instruments while one still awaits the defined internal review. The current equipment summary should reflect the actual authorized state for each item, rather than inheriting a group completed label from the overall work order.

Consider a fictional group of four instruments. Three receive the approved target version; the fourth returns with an unexpected version because the supplier changed its service approach. The coordinator records the actual state and obtains clarification for that item. The fourth instrument does not become identical to the others merely because the invoice lists one group service line.

After the authorized reviews, reconcile the version history and affected documentation for each instrument. Preserve the previous versions and event dates for historical interpretation. A later assignment question may require identifying which software was present at the time, and today's fleet summary cannot answer that question by itself.

Close the group plan with the completed population, exceptions and decision references. If one item remains open, identify its owner and next evidence requirement without obscuring completed work on the others. This gives operations an honest availability picture and leaves a reviewable history of what actually changed, rather than an unsupported statement that the entire fleet was updated and approved uniformly.