BWTS Configuration Baseline Handover: Software, Settings and As-Built Evidence
Updated
A configuration baseline gives the vessel and shore team a controlled reference for diagnosing change. It records the installed software, approved parameters, as-built signals, recoverable backups and access history without duplicating the wider commissioning documentation package.
Request BWTS spare parts, annual calibration or ballast-water testing
Key takeaways
- Record every controller, HMI, firmware and application version against the vessel and approved configuration.
- Freeze readable parameter exports with units, ranges, source and acceptance history.
- Reconcile as-built I/O, network interfaces and forced or unused points against loop evidence.
- Store tested, recoverable backups with controlled media, prerequisites and restore ownership.
- Protect credentials while documenting authorised access, account review and remote-session history.
- Link every configuration change to approval, test evidence, rollback and a new baseline.
Identify the exact control build
Record the controller, HMI, PLC, remote I/O, drives, analysers and network-device identifiers, including serial numbers, firmware, application version, database revision and build date. Capture the time zone and clock source used by alarms and event logs so later comparisons are meaningful.
Tie every version to the vessel, system capacity and approved configuration. A screen label alone is insufficient: retain the vendor release identifier, checksum or controlled file name where available, and note any site-specific patch or parameter change made during installation.
Freeze the parameter baseline
Export setpoints, alarm thresholds, interlock states, flow limits, calibration factors, user-defined timers, network addresses and mode selections in a readable, revision-controlled format. Identify units, permissible ranges and whether each value is maker-set, project-set or vessel-adjustable.
Compare the as-left values with the approved manual, commissioning record and test evidence. Explain intentional deviations and record who accepted them. Never treat a parameter export as self-authenticating: preserve the source file, export date, tool version and operator identity.
Reconcile as-built I/O and interfaces
Hand over the final I/O list with tag, signal type, channel, terminal, normal state, alarm meaning, scaling, source and destination. Reconcile it against loop checks and the actual cabinet, field device and automation interface. Mark spare, unused, forced and bypassed points explicitly.
Include network topology, addresses, gateway or protocol settings and interface ownership where needed for recovery. Protect sensitive credentials while giving the authorised vessel and shore administrators a documented access route. A drawing that omits a late cable change is not an as-built baseline.
Create recoverable backups
Make controlled backups of application software, PLC or controller projects, HMI files, parameter exports, recipes, alarm databases and configuration utilities as applicable. Store a working copy onboard and a protected shore copy, with media identity, date, version, restore prerequisites and encryption or access controls recorded.
Test that the files can be read and, where authorised and safe, that a recovery procedure is technically credible. A backup that depends on an unavailable license, obsolete laptop or unknown password is not a recovery resource. Record what may be restored by ship staff and what requires specialist support.
Control accounts and configuration access
List administrator, engineer and operator roles, password custody, remote-access permissions, removable-media rules and account review dates. Disable obsolete project accounts and record any default credentials that must be changed. Access control should support safe operation without making recovery dependent on one individual.
Log remote sessions, software uploads, parameter edits and approved service access with date, purpose, user and resulting version. Do not place passwords in an unprotected handover folder. The configuration record should identify where credentials are controlled, not expose them to every document recipient.
Link every change to evidence
Maintain a configuration change register linking request, reason, risk review, affected files, approver, implementation date, test result and rollback point. Include changes made during troubleshooting, not only formal upgrades. A new software build without a corresponding parameter and I/O comparison creates an ambiguous baseline.
At handover, sign the baseline index and record unresolved differences, backup locations, access owners and next review date. Re-baseline after an authorised change and retain the prior version for traceability. This configuration record supports operation and investigation; it does not replace approval, commissioning or authority requirements.
Frequently asked questions
Which software details belong in the baseline?
Record controller, HMI, PLC, remote I/O and relevant network-device identifiers, firmware, application and database revisions, build dates and controlled file identifiers.
What makes a parameter export useful?
It should show values, units, ranges, source, export date, tool version and operator, then be compared with the approved configuration and as-left test evidence.
How should credentials be handed over?
Do not place passwords in an open document folder. Record authorised roles, custody, access route, remote-access controls and review dates in the controlled security process.
When should the configuration baseline be revised?
After an authorised software, parameter, I/O, network or access change, with the request, risk review, test result, rollback point and superseded version retained.
Sources
- IMO — commissioning resolution MEPC.325(75) — Commissioning testing and documentation context.
- IMO — BWMS Code, resolution MEPC.300(72) — Code framework for approval and testing of ballast-water management systems.
- IMO — BWM Convention and Guidelines — Convention obligations and associated guidance.
- IMO — compilation of BWM guidance — Compilation identifying BWM.2/Circ.62 contingency and BWM.2/Circ.42/Rev.2 sampling guidance.
Related articles
- BWTS Commissioning Punch Lists: Critical vs Deferred Items
- BWTS Sea Trial Planning: Ballast Water Test Conditions and Evidence
- BWTS Maintenance Deferral: How to Assess Risk and Set a Due Date
- What Is the IMO BWMS Code?
- What Is a Ballast Water Treatment System? Explained
- How Does BWTS Installation Work? Step by Step
Request spares, calibration or ballast-water testing
Include BWMS brand/model, vessel/IMO number, port/terminal, date/ETA and scope or part numbers. These links prepare an email draft; you must send it yourself.
- Request a parts quote — Sensors, TRO reagents, calibration kits and replacement parts. Confirm compatibility, availability and delivery for your installed system.
- Request a calibration booking — Annual instrument calibration with a calibration certificate for the work completed. OEM instructions, drift or applicable rules may require earlier work.
- Request testing coordination — Arrange sampling and testing with an appropriately qualified party for your IMO D-2, commissioning or other stated purpose.
Authorised Headway agent. Other-brand enquiries are independently reviewed; no OEM authorisation is claimed. Sea Clean is not an accredited laboratory or approving authority. Calibration does not demonstrate biological D-2 compliance. Attendance, testing scope and parts delivery are confirmed per enquiry.