Interfaces, dependencies and integration planning

An interface is a shared obligation

An interface describes a relationship across a boundary. Mechanical fit, transferred loads, power, heat, fluid, data and human interaction can each require specifications. Identify both sides, their responsible owners and the conditions in which the relationship must hold. A local document understood by only one team cannot establish compatibility.

For a data item, define the quantity, unit, range, representation, update behaviour and meaning of missing or invalid values. For a physical connection, relevant geometry, loads or environmental conditions may be needed. Do not confuse an illustrative list with a complete industry specification; the required details follow from the particular functions and consequences.

Follow an error through the relationship

Our original interface sends a duration of 2 intended as minutes. A receiver interpreting seconds obtains 2 s instead of 120 s. The factor 60 difference survives perfectly reliable transmission. Stating the field name and numeric range without its unit leaves this error possible.

Even a correct unit is incomplete when the start event differs. Does the duration begin at authorisation, display of the result or confirmation by the visitor? A timeout can also arrive while another operation remains pending. Define relevant states and event ordering, and check duplicated, delayed and absent messages where they affect the intended service.

Specify the state consequence of a received value

Define original illustrative agreement IC1 for the station/catalogue D1 representation: duration is in whole seconds, consistent with the configuration example later in this chapter. The catalogue owner produces the reply and the station owner consumes it. They jointly own the meaning and compatibility agreement; the building-network owner supplies relevant transport conditions. READY means a current reservation indication in this model, not a command or record confirming physical collection.

A new station request enters WAITING with a new opaque request ID. For an active ID, the first valid D1 reply with valid status and duration_s in the integer range 1–300 enters READY. Its expiry is the station’s local monotonic acceptance time plus that duration. This explicitly chooses acceptance, rather than card presentation or catalogue creation, as the interval’s start. It is an agreed teaching policy, not a recommended authorisation rule. A reply timeout is separately 0.5 s from sending the request; that failure rule is outside R1’s normal connected-path timing case.

At expiry, enter EXPIRED. An identical reply for the same ID does not restart the interval. A conflicting reply for that active ID, invalid/missing duration, unavailable status or unsupported representation enters UNAVAILABLE and records the reason. A reply for an inactive ID is ignored. A request with no reply by its 0.5 s timeout enters UNAVAILABLE; late replies cannot resurrect that closed request. A new request is needed. On restart, invalidate local indications/active IDs until a new request; collection reconciliation remains a separate obligation.

When an expiry or timeout and a message share the same timestamp, apply the expiry/timeout first. The event order matters: a duplicate arriving exactly at expiry cannot extend READY. All example times below use one controlled local clock, so no cross-machine clock-synchronisation accuracy is assumed.

Predict the non-nominal state before running the check

Nominal-plus-duplicate trace: send K7 at local time 9.9 s. Receive D1/K7/valid/duration_s=120 at 10 s. Store 120 seconds, enter READY and set expiry 130 s. Receive the identical K7 reply at 50 s: remain READY with expiry 130, not 170. At 130 s enter EXPIRED even if a duplicate has exactly that timestamp. These are falsifiable expected states, not just a check that a message arrived.

Invalid trace: send K8 at 200 s, then receive a valid-status reply at 200.1 s with duration_s missing. Enter UNAVAILABLE and retain the invalid-data reason; do not invent a duration or display READY. A later corrected reply cannot revive the closed K8. In the separate missing-message case, send K9 at 300 s and receive nothing: at 300.5 s enter UNAVAILABLE; a reply at 300.6 s remains ignored. Clear session IDs separate these cases.

Plan interactions before final assembly

Integration planning identifies the elements, their prerequisites, configurations, enabling equipment and evidence needed at each stage. A staged station plan might check a reader with a controlled record source, then the real catalogue interface, then the whole visitor task. Each stage should expose a particular relationship while keeping limitations visible.

A simulator is useful when an unavailable external service would otherwise block development. Record what it represents and which behaviours it omits. Passing against a simulator that never delays or returns invalid data cannot establish performance under those conditions. Retain anomalies, investigate their causes and repeat affected checks on the corrected configuration before treating the relationship as established.

Choose the next integration stage by its missing dependency

Use the stages below as a bounded plan, not a claim that these checks were performed. A clock-driven stub is enough to falsify the local duplicate/expiry logic. It cannot establish what the real catalogue encodes or how the actual reader/display behave. Move to the next dependency only with its prerequisite configuration and expected observations identified. Retain failures and any corrected version so a later pass has a defined subject.

A D2 consumer interprets whole milliseconds while D1 uses whole seconds. If a D1 reply 120 is wrongly accepted as milliseconds, a reply received at 10 s expires at 10.12 rather than 130 s. A P1 stub already converted to D2 would hide the mixed-version fault. P2 therefore needs real wire representation and agreement about both ends, with a mismatch rejected rather than silently guessed. P3 then checks whether the physical visible event matches the earlier internal-state expectations.

Turn a compatibility issue into a targeted check

The station team writes a shared contract for duration in seconds, identifies its start event and specifies the relevant invalid-data behaviour with the catalogue owner. A supplied test case encodes 120 and observes both the receiver’s stored duration and the corresponding state transition under a controlled clock.

This check targets unit interpretation and timing semantics. It does not establish mechanical fit, network resilience or the complete visitor service. Link it to the interface obligation, identify the tested versions and retain the observation. Additional integration cases should target other relevant paths rather than repeating only the nominal message until the result looks reassuring.

Try the reasoning

1. Can reliable delivery prevent a unit mismatch?

   Show the answer and reasoning

   No. Reliability of transport and agreement about meaning are different properties.

2. Why identify the duration’s start event?

   Show the answer and reasoning

   A correctly expressed interval can still expire at the wrong point when the two sides use different starting events.

3. What does a nominal simulator test leave unresolved?

   Show the answer and reasoning

   Any relevant real-service behaviour that the simulator does not represent, such as delay, failures or different data states.

4. A valid 120-second reply first arrives at 5 s and an identical duplicate arrives at 50 s. What happens at 125 s under IC1, including a duplicate at that same instant?

   Show the answer and reasoning

   The first reply sets expiry 5+120=125 s. The duplicate at 50 does not reset it. At 125 the expiry event is applied first and the indication becomes EXPIRED; the simultaneous duplicate cannot restore READY. A new request/valid result would be a different session event, not an extension caused by replaying the old reply.

5. P1 passes with a D2 millisecond stub, but the independently owned catalogue still emits D1 seconds. Which integration dependency is missing, and what concrete fault could remain?

   Show the answer and reasoning

   Agreement and observation of the real producer/consumer representation in P2 are missing. A value 120 from D1 could become 0.12 s in the D2 consumer, expiring at 10.12 s for a 10 s acceptance instead of 130 s. Capture the actual versioned wire value and expected state with both owners; a locally consistent converted stub cannot establish mixed-version compatibility.

What to carry forward

Agree on both sides of every consequential interface and gather evidence about their interaction in known configurations and conditions.