Application and connectivity engineers
Preserve meaning, safety and trust as device data and commands cross gateways, applications, services and human interfaces.
After this module, you should be able to:
- Define end-to-end data and command semantics
- Design for intermittent, delayed and duplicated communication
- Protect identity, authorisation and update paths
- Verify compatibility across product and service versions
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-104 and TEA-107. Familiarity with application interfaces and client–server communication is useful.
A connected product is a distributed embedded system.
Mobile apps, gateways and cloud services may influence configuration, alarms, updates and control. Application engineers must understand device constraints and physical consequences, while firmware engineers need clear protocol and lifecycle contracts.
Define semantics beyond the payload schema.
| Area | Questions to resolve | Evidence |
|---|---|---|
| Identity | How are device, user, service and software version authenticated? | Identity model and credential lifecycle |
| Data meaning | What are units, timestamps, quality, origin and retention rules? | Versioned data contract |
| Commands | Who may request what, for how long, and how is outcome confirmed? | Authorisation and command-state model |
| Resilience | What happens offline, after retry or after conflicting updates? | Synchronisation and recovery rules |
| Evolution | Which device, API and app versions interoperate? | Compatibility matrix |
Separate receipt from effect
A transport acknowledgement proves that bytes arrived, not that the physical action occurred. Model requested, accepted, executing, completed, failed and expired states where commands have real-world consequences.
Test the seams and the degraded modes.
- Map trust boundaries. Identify principals, credentials, stores and administrative paths.
- Define contracts. Include semantics, error codes, idempotency and version rules.
- Model disconnection. Decide what is cached, retried, rejected or resolved locally.
- Make state visible. Distinguish stale, unknown, pending and confirmed information.
- Exercise compatibility. Test supported combinations and staged rollout order.
- Retain audit context. Link requests, decisions, device responses and software identities.
Worked hand-off: remote configuration limit
The app constrains the user input and displays device state, but the device independently validates the permitted range. The protocol carries units, schema version, command identifier and expiry. The service records the authorised requester; firmware reports applied or rejected with a reason. Tests cover duplication, stale commands and rollback.
Demonstrate the end-to-end behaviour.
Messages, states, errors, timing and compatibility rules.
Trust boundaries, assets, abuse cases and controls.
Provisioning, rotation, revocation and recovery.
Loss, delay, duplication, reordering and reconnection.
Supported device, API, gateway and application combinations.
Correlated events from request through physical outcome.
Common traps
Loss of service leaves behaviour or status undefined.
Field types exist, but meaning and lifecycle are ambiguous.
The app validates inputs that the device accepts blindly.
A service change assumes every deployed device updates at once.
Preserve meaning across device, application and service
A connected product can have several clocks, queues and versions. Define where each value originated, when it was acquired, whether it is valid and what configuration produced it. A recent database timestamp may describe upload time rather than measurement time.
Separate desired state from reported state. The application may request a target while the device rejects it or remains in transition. Displaying the requested value as the achieved condition can mislead the user. Represent pending, completed, failed and uncertain operations explicitly.
Specify which decisions remain local. A device that depends on a remote service for an essential protective response inherits network and service availability assumptions. Agree local behaviour during disconnection and the evidence required before synchronisation restores full operation.
Design reconciliation as a product behaviour
Retries, duplicate messages and reconnection are normal distributed-system conditions. Use operation identity and a defined deduplication policy where repeating an action has consequences. A fresh connection must not replay stale commands as though they were newly authorised.
Reconcile device state, local records and remote records after interruption. Identify the authoritative source for each fact. If delivery outcome is uncertain, preserve the uncertainty and the recovery procedure rather than fabricating a successful or failed result from incomplete data.
Plan version compatibility in both directions. A newer application may need to reject a capability on an older device; an older application must not silently misinterpret a new status value. Use explicit unsupported or unknown states and test the intended compatibility matrix.
| Information | Preserve across the boundary |
|---|---|
| Measurement | Acquisition time, units, validity and configuration. |
| Command | Authority, operation identity, target and expiry policy. |
| Completion | Physical outcome, result confidence and related operation. |
| Connectivity | Last confirmed contact and limits on current knowledge. |
Verify the user-visible consequence of a network fault
Test a disconnect before acceptance, after acceptance and after the physical action but before completion is received. These cases require different reconciliation. Add delays and reordered responses where the infrastructure can produce them, and observe both the device and what the user sees.
Protect logs and data stores from unbounded offline accumulation. Define capacity, retention and overflow behaviour. If an essential record cannot be stored, the product needs a specified response. A cloud outage should not quietly convert a valid operation into an untraceable one.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Correct a misleading success screen
An application shows “Completed” as soon as its command API returns HTTP 200. The gateway returns 200 after queueing, before the device has accepted the request.
- Define distinct gateway, device-acceptance and physical-completion states.
- Describe the display when connectivity is lost after queueing.
- Specify tests for delayed, failed and duplicate outcomes.
Show the worked answer
Treat gateway receipt as queued or pending. Device acceptance confirms that the device took responsibility under the command contract; completion must refer to the actual device outcome. Carry one operation identity through the chain and present uncertainty when the final state is not known.
After connection loss, do not turn a timeout into either guaranteed failure or success. Reconcile the operation when contact returns, using the device’s authoritative record and the duplicate policy. Test a rejected request, a delayed completion, a lost reply and an application restart. Check that the displayed state and any stored result match the evidence in every case.
Review criteria
- HTTP delivery is not confused with physical completion.
- Uncertainty has a deliberate user-visible state.
- Reconciliation preserves operation identity.
Check your understanding
Why retain both acquisition and upload time?
They answer different questions: when the physical observation occurred and when another system received it.
Can reconnecting justify replaying every queued command?
No. Commands may be expired, duplicated or no longer authorised in the current device state.
Further learning
- NIST SP 800-160 Volume 1Systems security engineering principles and lifecycle practices.
- TEA-104 · Communications interfaces and protocolsFraming, integrity, timing and recovery fundamentals.
Engineer continuity of meaning.
Reliable connectivity preserves identity, authorisation, data quality and command intent across unreliable networks and independently changing components.