The previous seven chapters described what WIA-ENE-040 asks a system to do: the Phase 1 messages and records, the Phase 2 and records APIs, the Phase 3 acoustic stack and the Phase 4 connections to networks, repositories and clouds. This last chapter asks the question a buyer, a reviewer or a certification committee will ask: how do you show that a system does it? A claim of conformance is only as good as the tests behind it. It is also only as clear as the level it names, and WIA-ENE-040 currently defines two sets of levels that do not mean the same thing.
The chapter first reconciles the two sets of levels. It then reads the Phase 3 protocol tests against the physics of sound in water, builds a test suite for data, API and SDK conformance, and walks through the certification process as the specification describes it. It closes with an implementer's checklist of pitfalls and a list of open issues and proposed errata collected across this book. Throughout, the chapter separates what the standard states from what this book recommends, and it marks every recommendation as the book's own.
Two documents in the standard define "Level 1", "Level 2" and "Level 3", and the definitions are different. Phase 1 §6.1 defines compliance levels for the data format alone. Phase 4 §8.1 defines certification levels for a whole system. A statement such as "our system is Level 2 compliant" is therefore ambiguous: it may mean the system implements every Phase 1 data type, or that it implements all four phases and integrates with three research networks. Those are very different commitments.
| Source | Level | What the specification requires |
|---|---|---|
| Phase 1 §6.1 (data format) | Level 1 (Basic) | Core message format with required fields |
| Level 2 (Standard) | All Phase 1 data types | |
| Level 3 (Advanced) | Binary format and full validation | |
| Phase 4 §8.1 (system certification) | Level 1 (Basic) | Phase 1 data formats, Phase 2 API access, basic integration with one major repository |
| Level 2 (Standard) | All four phases, integration with three or more research networks, ISO 19115 metadata compliance | |
| Level 3 (Advanced) | Real-time streaming integration, cloud-native architecture, machine-learning pipeline integration, 99.9% uptime SLA |
The two scales measure different things, so neither should be read as a stricter version of the other. The Phase 1 scale describes how much of the data format an implementation speaks. The Phase 4 scale describes how far the system reaches: API, protocol, networks, metadata and operations. This book proposes to treat them as two axes and to name them differently so that they cannot be confused:
A conformance claim then states both, for example "WIA-ENE-040 v1.0, C2 / F3". The matrix below shows which combinations make sense. The cells are this book's proposal, not text from the standard.
| Certification level | F1 (envelope) | F2 (all data types) | F3 (binary + full validation) |
|---|---|---|---|
| C1: formats, API, one repository | Allowed for a narrow product, such as a sensor gateway that emits only one message type | Typical | Allowed |
| C2: all phases, 3+ networks, ISO 19115 | Not coherent: repository and network mappings need the typed payloads | Allowed for shore-side systems without acoustic links | Expected for any system that operates acoustic links |
| C3: streaming, cloud, ML, 99.9% SLA | Not coherent | Allowed if no binary transport is used | Typical |
Two further problems appear once the levels are laid side by side. First, C2 requires "all 4 phases", but many systems that would reasonably seek C2 never touch an acoustic modem. A shore-side data centre, a repository or an analysis platform receives data after recovery or over a satellite link. As written, such a system can never exceed C1. The practical reading is to let a claimant declare Phase 3 "not applicable" with a reason, and to test Phase 3 only for products that transmit or receive acoustically. A committee should decide this explicitly rather than leave each reviewer to improvise.
Second, several C3 criteria are not testable in a certification run. "Cloud-native architecture" and "machine-learning pipeline integration" are descriptions, not pass/fail criteria. A 99.9% uptime SLA is an operational commitment. Over a year it allows roughly 8.8 hours of downtime (0.1% of 8,760 hours), and it can only be demonstrated from monitoring records over time, not by a test suite on one day. A C3 assessment should therefore ask for evidence: monitoring history, an incident log and the published SLA text, alongside the automated tests.
A machine-readable conformance statement makes a claim checkable. The shape below is this book's suggestion; the field names are not defined by the standard.
{
"standard": "WIA-ENE-040",
"standardVersion": "1.0",
"product": "Example Survey Data Hub",
"productVersion": "3.2.0",
"certificationLevel": "C2",
"formatProfile": "F2",
"phases": {
"phase1": { "status": "IMPLEMENTED", "messageTypes": ["OCEANOGRAPHIC_DATA", "BATHYMETRIC_DATA", "SAMPLE_METADATA", "VEHICLE_TELEMETRY"] },
"phase2": { "status": "IMPLEMENTED", "openapi": "https://api.example.org/v1/openapi.json" },
"phase3": { "status": "NOT_APPLICABLE", "reason": "No acoustic transmission; data arrive after recovery" },
"phase4": { "status": "IMPLEMENTED", "networks": ["NCEI", "PANGAEA", "BCO-DMO"], "metadata": "ISO 19115" }
},
"deviations": ["DEV-01", "DEV-02", "DEV-03"]
}The deviations list points to the documented deviations that the certification process requires (8.4). Given the gaps described in earlier chapters, an honest v1.0 implementation will almost always have some.
Phase 3 §10.1 lists the tests required for protocol compliance, grouped by layer. They fall into two kinds. Some are measurements of the equipment and can be made in a test tank. Others are end-to-end timing targets, and whether they can be met depends on distance, because sound travels at about 1,500 m/s in seawater. The table repeats each criterion and adds the dependence on range, which the specification does not discuss.
| Layer | Test (Phase 3 §10.1) | Criterion | Depends on range? |
|---|---|---|---|
| Physical | Frequency accuracy | ±10 Hz | No: equipment property |
| Power output | ±1 dB of specified | No: measured at a reference distance | |
| Modulation quality | EVM < −15 dB | No: measured on a clean channel | |
| Data link | FEC decoding | BER < 10⁻⁶ after correction | Indirectly: depends on SNR, so the test SNR must be stated |
| ARQ | Successful retransmission | No | |
| Frame parsing | 100% success | No | |
| Network | Route discovery | < 30 s | Yes, strongly |
| Link-failure detection | < 60 s | Depends on the HELLO interval, which is not specified | |
| Loop prevention | Verified | No | |
| Transport | Connection establishment | < 15 s | Yes |
| Reliable delivery | 100% for non-timeout cases | No | |
| Fragmentation/reassembly | Verified up to 10 KB | Only through the 120 s reassembly timeout | |
| Application | Command/response | End-to-end < 60 s | Yes |
| Telemetry | Delivery rate > 95% | Yes, through channel quality | |
| Emergency alert | Delivery < 5 s | Yes, decisively |
Frequency accuracy, power output and EVM are properties of the transmitter. They are measured in a test tank or at a calibration facility with a calibrated hydrophone. Source level is expressed in dB re 1 µPa at 1 m, so the measured level at the hydrophone distance must be corrected back to 1 m. The ±1 dB tolerance is tight compared with the uncertainty of many hydrophone calibrations, so the report must state the hydrophone's calibration uncertainty. Otherwise a pass or fail within ±1 dB means little.
A bit-error-rate target cannot be verified by sending a few frames. If no errors are seen in n bits, the 95% upper confidence bound on the error rate is about 3/n (the "rule of three"). Showing BER < 10⁻⁶ therefore needs at least about 3 × 10⁶ error-free bits. At 5 kbps that is 600 s of continuous payload. At 100 bps, the bottom of the VLF band, it is 30,000 s, more than eight hours. The practical approach is to run the decoder test on recorded or simulated baseband signals, injected at a stated SNR through a channel emulator, and to use in-water trials only to confirm the result at one or two operating points. The test report must state the SNR and the channel model; "BER < 10⁻⁶" without them is not a verifiable claim.
The end-to-end targets meet a hard floor: one-way propagation time is distance divided by sound speed. Taking 1,500 m/s (real sound speed varies with temperature, salinity and pressure, roughly between 1,450 and 1,550 m/s):
| Distance | One way | Round trip | Typical band (Phase 3 §2.1) |
|---|---|---|---|
| 1 km | 0.67 s | 1.3 s | HF / MF |
| 5 km | 3.3 s | 6.7 s | MF / LF |
| 10 km | 6.7 s | 13.3 s | LF / VLF |
| 20 km | 13.3 s | 26.7 s | VLF |
To propagation add airtime (frame bits divided by data rate) and MAC waiting. Under the TDMA scheme of Phase 3 §3.4 a node may wait up to a full superframe for its slot, which is 9 s by the stated components (see the erratum in 8.6). With these three terms the targets can be checked one by one.
Two more tests deserve a note. The telemetry delivery rate (> 95%) depends on channel conditions that change with weather, noise and geometry, so it should be measured over a stated period and range and reported with those conditions. The fragmentation test (up to 10 KB) is straightforward arithmetic: a 6-byte fragment header (16-bit ID, 8-bit number, 8-bit total, 16-bit offset), carried in a 256-byte payload, leaves 250 bytes of data, so 10,240 bytes need 41 fragments. The 8-bit total allows up to 255 fragments and the 16-bit offset caps a message at 65,535 bytes; larger files belong to WIA-UFTP. The test should also check that all 41 fragments can arrive within the 120 s reassembly timeout at the tested data rate. Allowing for framing overhead, at 2 kbps 10 KB takes more than 40 s of airtime and fits on a dedicated link; at 500 bps it takes more than 160 s and cannot fit. Under TDMA with one slot per superframe it cannot fit at any rate, which is why Chapter 6 recommends reading the timeout as an inactivity timer.
The general lesson is that a Phase 3 test report without a stated band, range and channel condition proves little. This book recommends that every timing result be reported as a triple: (criterion, band, distance). Tank and short-range sea trials can demonstrate the timing targets; long-range VLF operation should be tested against targets rescaled for propagation.
The standard requires an "official validation test suite" (Phase 1 §6.2) and shows the output of an automated tool, wia-dse-certify (Phase 4 §8.2). The suite itself is not published with the specification examined for this book. An implementer who wants to be ready for certification should build an equivalent suite now. The same suite then serves as a regression net for every release. The catalogue below lists the tests this book recommends, with identifiers that the later sections refer to. The identifiers and grouping are the book's own.
| ID | Phase | Criterion | Method |
|---|---|---|---|
| P1-ENV-01 | 1 | All required envelope fields present and typed (§3.1) | Golden fixtures plus one fixture per missing field |
| P1-ENV-02 | 1 | sequenceNumber monotonic per sourceId; gap and repeat detected | Stream of fixtures with a gap, a duplicate and a reset |
| P1-ENV-03 | 1 | sourceId charset: letters, digits, hyphen, underscore | Fixtures with space, dot and non-ASCII characters |
| P1-RNG-01 | 1 | Range table of §3.2 enforced; OUT_OF_RANGE reported | Boundary values, just inside and just outside |
| P1-RNG-02 | 1 | Heading normalised to [0, 360); 359.99 and 0 accepted, 360 normalised or rejected consistently | Wrap-around fixtures |
| P1-CHK-01 | 1 | Checksum computed over canonical payload bytes | Same payload with reordered keys and different whitespace yields the same digest |
| P1-CHK-02 | 1 | Digest of empty input rejected | Fixture carrying e3b0c442…b855 |
| P1-BIN-01 | 1 | 32-byte header round trip; big-endian; magic WIAE | Encode → decode → compare; byte-exact golden header |
| P1-BIN-02 | 1 | Payload length never exceeds bytes received | Truncated and oversize-length buffers |
| P1-TIM-01 | 1 | UTC within ±1 s or drift documented (§3.3) | Archive without time-sync metadata must fail |
| P2-API-01 | 2 | Responses match the OpenAPI 3.0 description | Contract tests generated from the OpenAPI file |
| P2-API-02 | 2 | Error envelope and codes (400, 401, 403, 404, 429, 500, 503) | Negative requests per code |
| P2-API-03 | 2 | Rate-limit headers present; 429 honoured by clients | Burst above tier limit |
| P2-API-04 | 2 | Repeated command with the same identifier executes once | Replay after a simulated timeout |
| SDK-01 | 2 | Pressure helper physically correct | Regression against ρgh reference values |
| P3-* | 3 | The Phase 3 §10.1 tests in 8.2, with band and range stated | Tank, emulator and sea trial |
| P4-MAP-01 | 4 | Unit conversions in repository mappings (for example bar → dbar × 10) | Round trip through the export and back |
| P4-ACC-01 | 4 | No confidential coordinates in public products | Scan public outputs against the confidential list |
The core of a data-format suite is a set of golden fixtures: small, hand-checked files whose correct outcome is known. Keep them in version control next to the code, one file per case, with the expected result in the file name or in a sidecar file. The valid set should include one message of every implemented type, since certification requires sample data for each (Phase 1 §6.2). The invalid set should include one fixture for each rule. Edge cases worth a fixture each:
Z, and one malformed in the way of the spec's DiveLog example (2025-03-15-15:30:00Z). All three must be rejected or normalised consistently.Chapter 3 recommended computing the checksum as SHA-256 over the JCS (RFC 8785) canonical form of the payload. The test that matters is invariance: the same payload with its keys reordered and its whitespace changed must give the same digest, and a one-character change in any value must change it. A second test rejects the digest of empty input, e3b0c442…b855, which appears in the specification's example and indicates that nothing was hashed. For the binary header, one byte-exact golden header (such as the one printed in Chapter 3) protects against a byte-order change, and a round-trip test covers the fields.
Phase 2 states that an OpenAPI 3.0 description is available. Contract tests derived from that description check that every documented path returns the documented status codes and response shapes, and that undocumented fields do not leak. Run them against a staging deployment seeded with fixture data, never against live mission data. The negative tests matter as much as the positive ones: a request for a waypoint deeper than the vehicle rating must return the documented INVALID_DEPTH_PARAMETER error, and a burst of requests above the tier limit must return 429 with the X-RateLimit-* headers.
The shipped SDK @wia/ene-040 already configures Jest (ts-jest, test files under src). The file below shows the three kinds of test in one place. The validator and header codec are minimal versions written for this example; in a real project they would be imported from the implementation under test. The pressure test uses test.failing, available in the Jest 29 line the SDK depends on. It documents the known bug in calculatePressure(), whose mpa value is ten times too small, and it will start to report a failure the day the bug is fixed, prompting the team to turn it into an ordinary test.
// src/__tests__/conformance.test.ts
import { calculatePressure } from '../index';
// ---- minimal range validator (Phase 1 §3.2) ----
type Flag = { path: string; value: number; flag: 'OUT_OF_RANGE' };
const RANGES: Record<string, [number, number]> = {
depth: [0, 11000], temperature: [-2, 400], pressure: [0, 1100],
salinity: [0, 50], pH: [0, 14], dissolvedOxygen: [0, 20],
latitude: [-90, 90], longitude: [-180, 180],
};
function checkRanges(values: Record<string, number>): Flag[] {
return Object.entries(values)
.filter(([k, v]) => k in RANGES && (v < RANGES[k][0] || v > RANGES[k][1]))
.map(([k, v]) => ({ path: k, value: v, flag: 'OUT_OF_RANGE' }));
}
// ---- minimal 32-byte header codec (Phase 1 §4.1, big-endian) ----
const MAGIC = 0x57494145; // "WIAE"
interface Header { major: number; minor: number; type: number; priority: number;
timestampNs: bigint; seq: number; sourceHash: bigint; payloadLength: number; }
function encodeHeader(h: Header): Uint8Array {
const buf = new Uint8Array(32); const v = new DataView(buf.buffer);
v.setUint32(0, MAGIC); v.setUint8(4, h.major); v.setUint8(5, h.minor);
v.setUint8(6, h.type); v.setUint8(7, h.priority);
v.setBigInt64(8, h.timestampNs); v.setUint32(16, h.seq);
v.setBigUint64(20, h.sourceHash); v.setUint32(28, h.payloadLength);
return buf;
}
function decodeHeader(buf: Uint8Array): Header {
if (buf.length < 32) throw new Error('short header');
const v = new DataView(buf.buffer, buf.byteOffset, 32);
if (v.getUint32(0) !== MAGIC) throw new Error('bad magic');
return { major: v.getUint8(4), minor: v.getUint8(5), type: v.getUint8(6),
priority: v.getUint8(7), timestampNs: v.getBigInt64(8), seq: v.getUint32(16),
sourceHash: v.getBigUint64(20), payloadLength: v.getUint32(28) };
}
describe('P1-RNG-01 range validation', () => {
test.each([
['depth', 0, 0], ['depth', 11000, 0], ['depth', 11000.1, 1],
['temperature', -2, 0], ['temperature', 400, 0], ['temperature', -2.1, 1],
['latitude', 90, 0], ['latitude', 90.0001, 1],
])('%s = %p gives %p flag(s)', (field, value, expected) => {
expect(checkRanges({ [field as string]: value as number })).toHaveLength(expected as number);
});
});
describe('P1-BIN-01 header round trip', () => {
const h: Header = { major: 1, minor: 0, type: 0x01, priority: 1,
timestampNs: 1736951400000000000n, seq: 12345,
sourceHash: 0x7ffa1d7427532e15n, payloadLength: 118 };
test('is 32 bytes and starts with ASCII "WIAE"', () => {
const b = encodeHeader(h);
expect(b).toHaveLength(32);
expect(Buffer.from(b.subarray(0, 4)).toString('ascii')).toBe('WIAE');
});
test('decodes to the same values', () => {
expect(decodeHeader(encodeHeader(h))).toEqual(h);
});
test('rejects a little-endian magic', () => {
const b = encodeHeader(h); b.set([0x45, 0x41, 0x49, 0x57], 0);
expect(() => decodeHeader(b)).toThrow('bad magic');
});
});
describe('SDK-01 pressure helper', () => {
// Reference: P_abs = 101325 Pa + rho*g*h, rho = 1025 kg/m^3, g = 9.81 m/s^2
const ref = (d: number) => (101325 + 1025 * 9.81 * d) / 1e6; // MPa
// Known bug: mpa is 10x too small (1,000 m gives about 1.0 MPa, not about 10.16).
test.failing('mpa matches hydrostatics at 1,000 m', () => {
expect(calculatePressure(1000).mpa).toBeCloseTo(ref(1000), 1);
});
test('reference value itself is sane', () => {
expect(ref(1000)).toBeCloseTo(10.157, 2);
});
});The golden header values match the Chapter 3 example, so the TypeScript and Python codecs are checked against the same bytes: two implementations agree with a file, not merely with themselves.
Phase 4 §8.2 shows wia-dse-certify --level N printing a pass count per phase, the failing checks by name, and an overall status. That is a good model for an in-house report because it separates phases and names each failure. The report below follows that shape. The product, the counts and the failure are illustrative only, and the book adds the two fields a reviewer will ask for: the format profile, and the phases declared not applicable.
WIA-ENE-040 conformance run (in-house, illustrative)
Target: https://api.example.org/v1 Product: Example Survey Data Hub 3.2.0
Claim: C2 / F2 Spec: WIA-ENE-040 v1.0
Deviations on file: DEV-01 checksum canonicalisation (JCS)
DEV-02 binary byte order (big-endian)
DEV-03 message-type codes (book working registry)
Phase 1 Data format PASS 62/62
Phase 2 API interface PASS 38/38
Phase 3 Protocol N/A (no acoustic transmission; declared)
Phase 4 Integration FAIL 17/18
x P4-ACC-01 public 50 m grid tile contains a point within 200 m
of a confidential site (layer: survey-overview)
Result: NOT READY - fix P4-ACC-01 and re-runPhase 1 §6.2 and Phase 4 §8 together describe the process. The steps below combine the two texts without adding requirements the specification does not state. The specification does not name fees, timelines or the composition of the WIA certification committee, and this book does not supply them.
[1] Self-assessment ---- run the validation suite in-house
|
v
[2] Submission --------- sample data for every implemented message type
| + conformance statement (C-level / F-profile)
| + documented extensions and deviations
v
[3] Automated testing -- official validation suite (wia-dse-certify)
|
v
[4] Manual review ------ documentation, code quality, security, performance
|
v
[5] Committee peer review
|
pass | fail -> findings returned -> back to [1]
v
[6] Certificate -------- signed digital certificate, badge, directory listing
|
v
[7] Annual renewal ----- re-run on the current release, update deviationsSample data for every implemented type. Phase 1 §6.2 requires sample data that demonstrates all implemented message types. The sample data should come from real equipment or realistic simulation, not only from hand-written fixtures, and it must carry no real confidential coordinates or personal data. Chapter 4's access tiers apply to certification samples as much as to published data.
Documented extensions and deviations. Every place where an implementation had to choose because the specification is silent belongs here: the checksum canonicalisation, the binary byte order and version packing, the source-ID hash, the binary message-type codes, the location of the OUT_OF_RANGE flag, and any Protobuf schema the implementer wrote. A deviation document is not a confession of failure. It is what lets a second implementation interoperate with the first. A useful entry names the specification clause, states the choice, gives the reason and lists the tests that verify it.
Manual review. Phase 4 §8.2 lists four areas: documentation completeness, code quality, security audit and performance benchmarking. For a WIA-ENE-040 system, the security review should concentrate on the parts the standard makes security-relevant: authentication on the Phase 2 API (OAuth 2.0 bearer tokens or API keys), the RBAC roles and embargo logic of Phase 4 §7, and the handling of confidential coordinates. Performance benchmarking should be tied to declared figures, such as the rate-limit tiers the service offers, rather than to open-ended claims.
Deliverables and renewal. A successful applicant receives a digital certificate signed by WIA, a badge for its website and publications, and a listing in the directory of certified systems. Certification must be renewed annually. At renewal, re-run the full suite on the current release and diff the deviation document against last year's.
Two cautions about claims. A certificate covers a named product version at a named level. It says nothing about other versions, and it is not an endorsement by any of the research organisations named in the specification's contributor lines. Marketing text should say exactly what was certified: level, profile, version and date.
The pitfalls below come from the gaps and inconsistencies identified in earlier chapters and from the failure modes typical of systems that move data from a vehicle to a ship, to shore and on to an archive. Each has a test from 8.3 that catches it.
| Pitfall | What goes wrong | Prevention | Test |
|---|---|---|---|
| Timestamp drift | Vehicle clock drifts during a dive; timestamps leave the ±1 s window | Record GPS offsets before and after the dive and correct linearly; document drift (§3.3). Remember that raw GPS time is 18 s ahead of UTC | P1-TIM-01 |
| Missing units and calibration dates | Values cannot be compared or re-processed; repository submission rejected | Use the measured-value object (value, unit, sensorId, calibrationDate) everywhere, including fields where the spec example omits units | P1-ENV-01 |
| Byte order | Binary headers decode as nonsense on another platform | Big-endian throughout; check the magic reads WIAE | P1-BIN-01 |
| Heading in a signed 16-bit field | Signed 16-bit centidegrees hold at most 327.67°, so headings from 327.68° to 359.99° overflow | Unsigned 16-bit centidegrees (0–35,999) and normalisation to [0, 360) | P1-RNG-02 |
| Depth units: JSON vs binary | JSON carries metres; the Phase 3 compact telemetry carries unsigned 16-bit centimetres, which saturate at 655.35 m | Do not use the compact record for deep-sea depth; use a wider field or decimetres, and declare units in every encoding | P1-BIN-01, P3-* |
| Vent temperatures in compact telemetry | Signed 16-bit hundredths of a degree stop at 327.67 °C, below the 400 °C range limit | Use tenths of a degree or a wider field for vent-probe data | P3-* |
| Rate-limit handling | Clients retry immediately after a 429 and stay blocked | Honour X-RateLimit-Reset; back off exponentially with jitter | P2-API-03 |
| Non-idempotent command retries | A timed-out command is resent and executed twice, such as a second sampler trigger | Reuse the same commandId on retry; the vehicle discards duplicates it has already acknowledged | P2-API-04 |
| Confidential coordinates leaking | A sensitive site is protected in the records but is visible in a public grid, an image's embedded GPS tag, a dataset bounding box or an observation's coordinates | Generalise coordinates in every public product, not only in the record; scan outputs before release | P4-ACC-01 |
| Sequence and time wrap | Receivers treat a wrapped 16-bit link sequence as a replay; 32-bit Unix seconds in the link header overflow in 2038 | Wrap-aware comparison; plan a header revision before 2038 | P1-ENV-02 |
Two items deserve a closer look. The confidential-coordinate leak is the one most likely to cause real harm, because a published location cannot be recalled. Generalisation rules must be applied at the moment a public product is made. They must also be applied consistently, since a site that is blurred in one product but exact in another is exposed by the second. The idempotency pitfall is specific to acoustic links. A timeout does not mean the command was lost: the command may have been executed and only the acknowledgement lost. On a channel where timeouts are routine, a retry that is not idempotent will sooner or later execute an action twice. The Phase 3 command message already carries a commandId, and making the receiver deduplicate on it is cheap.
Phase 4 §10 lists integrations and technologies the committee plans to address. They are stated there as intentions for 2025–2027, and this book treats them as such: none is part of v1.0 and none can be certified today. The items most relevant to implementers are:
Writing this book meant reading the specification, the SDK and the CLI side by side, and a number of inconsistencies surfaced. The table collects them as a proposed change list for a v1.x revision. Each entry is this book's finding and proposal. None has been adopted by the standard.
| No. | Where | Issue | Proposed change |
|---|---|---|---|
| E1 | ENE-040 §9.1 | "P(bar) = 1 + depth/10" treats bar and atm as equal; the MPa formula is dimensionally wrong | P = 101.325 kPa + ρgh, with ρ and g stated |
| E2 | SDK calculatePressure() | mpa is ten times too small | Compute from ρgh; add regression test SDK-01 |
| E3 | Phase 1 §3.1, §2.1 | Checksum input and canonicalisation undefined; example digest is of empty input | SHA-256 over JCS (RFC 8785) payload bytes; replace the example |
| E4 | Phase 1 §4 | Binary byte order, version packing, source hash and type codes unspecified; no closed messageType list; Protobuf schemas not supplied | Specify big-endian, the hash and a published registry of message types with their codes; publish .proto files |
| E5 | Phase 1 §3.2 | Pressure limit (1,100 bar) is below the hydrostatic value at the depth limit (about 1,107 bar); pressure reference not stated | Raise the limit or derive it from depth; state absolute or sea pressure |
| E6 | Phase 1 §6.1 and Phase 4 §8.1 | Two different "Level 1–3" scales | Rename to format profiles and certification levels (8.1) |
| E7 | Phase 3 §3.4 | Superframe stated as 10 s; components sum to 9 s | State 9 s, or add explicit guard time to reach 10 s |
| E8 | Phase 3 §4.1 | Multicast 0xFF00–0xFFFE overlaps Network ID 255 | Reserve Network ID 255 for multicast and broadcast |
| E9 | Phase 3 §3.1 | 32-bit Unix-second timestamp overflows in 2038 | Plan a header version with a wider or epoch-relative time |
| E10 | Phase 3 §6.2 | Compact telemetry depth caps at 655.35 m; temperature caps at 327.67 °C | Redefine field widths and resolutions for full ocean depth and vent temperatures |
| E11 | Phase 3 §10.1 | Emergency < 5 s and other timing targets ignore propagation at the specified ranges | Scope each target by band and distance |
| E12 | Phase 3 §4.2 | HELLO interval not specified, so link-failure detection cannot be tested consistently | Specify a default interval and miss count |
| E13 | ENE-040 §5.2.1 | ROV fibre latency of 100–500 ms "by depth" is not consistent with propagation in fibre | Remove, or replace with a measured end-to-end system latency and its components |
| E14 | ENE-040 §12 example | Malformed offBottom timestamp | Correct the example; validate examples in CI |
| E15 | ENE-040 vent record | Fluid chemistry values without units | Use measured-value objects with units |
| E16 | Phase 4 §3.1 | OOI temperature mapping converts to Kelvin, although CF/OOI temperature is commonly in degC | Convert according to the target's declared units |
| E17 | README vs SDK | README names @wia/deep-sea-exploration and WIADeepSeaClient; the shipped package is @wia/ene-040 with DeepSeaExplorationSDK | Align the README with the shipped code |
| E18 | All documents | Several different example host names | Use one reserved example domain throughout |
| E19 | Phase 4 §8.1 | C2 requires all four phases, excluding systems without acoustic links | Allow "not applicable" declarations with reasons |
| E20 | Phase 4 §5.2 | Recommends Azure Data Lake Analytics (U-SQL), which has been retired | Replace with a vendor-neutral processing pattern |
| E21 | Phase 3 §3.3, §4.2, §5.1, §5.2 | Further Phase 3 issues from Chapter 6: RS codeword size and interleaving delay (P3-3), route-cost units (P3-6), RTT update order (P3-7), fragment header and reassembly timeout (P3-8) | Adopt the resolutions in the Chapter 6 summary table |
| E22 | ENE-040 §12.3, §13; SDK DepthZone | depthZone mixes a benthic value (hadal) with the SDK's pelagic enumeration | Add a depthZoneScheme field, or separate pelagic and benthic fields |
| E23 | Phase 2 §3; SDK SubmersibleType | Two vehicle-type vocabularies (ROV, AUV, SUBMERSIBLE, GLIDER versus hov, rov, auv, lander, crawler) | One registry with a published mapping; add glider |
| E24 | Phase 2 commands | No terminal command states, so command.completed cannot report the outcome | Define COMPLETED, FAILED, CANCELLED and TIMED_OUT |
| E25 | Phase 2 mission example | Misspelt key imagesCaptures | Rename to imagesCaptured; accept both during a transition |
| E26 | ENE-040 §13; SDK and CLI | /api/v1/search and /api/v1/statistics are called by the tools but not specified | Add both to §13 with response schemas |
| E27 | Phase 2 missions; ENE-040 §12.2 | No field links a mission to its expedition and dive | Add expeditionId and diveId to missions and missionId to dive logs (the Section 2.4 convention) |
Most entries are small edits. Taken together, they decide whether two independent implementations of v1.0 can exchange data without a phone call between their authors. E3, E4, E6 and E10 matter most. Until the standard resolves them, an implementer's best course is the one this book has followed throughout: make the choice explicit, document it as a deviation, and test it.
WIA-ENE-040 covers a demanding domain. Its data come from instruments working under hundreds of bar, cross channels that carry a few kilobits per second with seconds of delay, and must end in archives that are still readable decades later. The standard's four phases give that journey a shared vocabulary. This chapter has argued that the vocabulary becomes a guarantee only when three things hold. A conformance claim must name its format profile and certification level. Timing claims must name band and range. Every silence in the specification that an implementer fills must be written down as a deviation. A system built and tested that way is ready for certification. It also leaves a record that the next engineer, and the next version of the standard, can build on.