11. Performance, Reliability, and Resilient Systems Engineering

Introduction and Context

Internet of Things (IoT) systems are often evaluated first by whether devices can sense, communicate, and actuate. At doctoral level, however, functional correctness is only the starting point. A useful IoT system must also deliver information within an acceptable time, sustain required workloads, conserve energy, remain available under faults, and continue to provide safe service when components, networks, or external dependencies fail. These properties are not independent. Increasing retransmissions may improve delivery reliability but consume energy; replication may improve availability but increase synchronization traffic; encryption may strengthen protection while adding latency and computational load.

Performance, reliability, and resilience engineering therefore treat an IoT deployment as a socio-technical system rather than a collection of devices. The system includes sensors, embedded software, wireless links, gateways, edge and cloud services, power supplies, operators, maintenance processes, and environmental conditions. Its behavior emerges from interactions among these elements. A design that performs well in a laboratory can fail in a factory, hospital, agricultural field, or transport network because interference, mobility, congestion, weather, human action, and maintenance constraints alter the operating context.

This chapter develops a framework for modeling and optimizing latency, throughput, availability, dependability, fault tolerance, quality of service (QoS), energy consumption, scalability, survivability, and real-time behavior. It connects analytical models with simulation, formal verification, testing, and empirical measurement. Particular attention is given to the danger of optimizing a single metric while degrading the system’s overall mission.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Distinguish performance, reliability, availability, dependability, resilience, survivability, and fault tolerance.

2. Construct useful latency, throughput, queueing, energy, and availability models for IoT systems.

3. Select appropriate simulation, formal-analysis, testing, and measurement techniques.

4. Analyze trade-offs among QoS, energy, scalability, safety, security, and cost.

5. Design fault-tolerant and resilient architectures for wireless and edge-enabled IoT.

6. Interpret empirical results using meaningful workloads, confidence intervals, and failure assumptions.

7. Evaluate an IoT architecture against real-time, operational, ethical, and governance requirements.

A Vocabulary of Dependability

Performance describes how efficiently a system provides service. Common dimensions include response time, latency, throughput, jitter, resource utilization, and energy per useful operation. Reliability is the probability that a system performs its required function without failure for a stated period and under stated conditions. Availability is the probability that the service is operational when it is required. A system can have high reliability over short missions but low availability if repair takes a long time; conversely, a frequently failing system may achieve high availability if failures are repaired almost immediately.

Dependability is a broader property encompassing attributes such as reliability, availability, safety, integrity, maintainability, and sometimes confidentiality. Fault tolerance is the capability to continue delivering an acceptable service in the presence of faults. Resilience concerns the ability to withstand, adapt to, recover from, and learn from disruptive events. Survivability emphasizes continued delivery of essential functions despite severe or hostile conditions. These concepts overlap but should not be treated as synonyms.

A useful distinction is among fault, error, and failure. A fault is a hypothesized cause of incorrect behavior, such as a damaged antenna, software defect, depleted battery, or malicious packet. An error is an incorrect internal state produced when a fault is activated. A failure occurs when the delivered service deviates from specified requirements. Faults may remain dormant, errors may be masked, and failures may be detected or remain latent.

Requirements must be stated quantitatively where possible. “Low latency” is inadequate without a bound, percentile, workload, and environmental assumptions. A requirement might state that 99.9 percent of emergency messages must reach the control service within 200 milliseconds during a specified traffic load, while noncritical telemetry may be delayed for several minutes. Such differentiated requirements are essential in resource-constrained wireless systems.

Modeling the Performance of IoT Workloads

Latency and jitter

End-to-end latency is not merely radio transmission time. A practical decomposition is

L_total = L_sense + L_queue + L_access + L_tx + L_prop + L_gateway + L_processing + L_cloud + L_actuation.

The terms represent sensing and sampling delay, queueing, medium-access delay, transmission, propagation, gateway handling, computation, remote service processing, and actuation. Some terms are variable and correlated. For example, congestion increases both queueing and retransmission delay. Reporting only the mean can conceal dangerous tail behavior; the 95th, 99th, or maximum latency may be more relevant for control and safety.

Jitter is the variation in delay. A system with an average latency of 20 milliseconds but occasional delays of several seconds may be unsuitable for closed-loop control. In real-time systems, a deadline miss ratio, worst-case response time, and temporal isolation are often more meaningful than an average.

Throughput, capacity, and goodput

Throughput is the rate at which data is transferred, while goodput measures useful application data after excluding headers, retransmissions, duplicated packets, and control traffic. Wireless capacity is constrained by channel bandwidth, coding, modulation, interference, duty-cycle rules, contention, and battery limitations. A nominal data rate therefore does not equal sustainable application capacity.

A basic utilization measure is

U = offered load / service capacity.

As utilization approaches one, queueing delay can increase sharply. In a simple single-server queue, the relationship between arrival rate, service rate, and waiting time can be approximated using queueing theory. The M/M/1 model, with Poisson arrivals and exponentially distributed service times, gives average system time as 1/(μ − λ), where λ is arrival rate and μ is service rate, provided λ < μ. IoT traffic rarely satisfies all M/M/1 assumptions, but the model provides insight: small increases in offered load near capacity can produce disproportionate delay.

Burstiness, correlated reporting, and alarm storms require richer models, such as priority queues, finite-buffer models, network calculus, stochastic simulations, or trace-driven evaluation. Critical alarms should not be analyzed as if they were independent periodic sensor reports.

Energy consumption and lifetime

For a battery-powered node, energy is consumed by sensing, computation, transmission, reception, idle listening, sleep-state transitions, security operations, and leakage. A first-order model is

E_total = E_sense + E_compute + E_tx + E_rx + E_idle + E_sleep.

Transmission energy is influenced by payload size, radio power, channel quality, retransmissions, and protocol overhead. The energy per successfully delivered bit is often more useful than energy per transmitted bit. A device that transmits cheaply but loses many packets may be less efficient than one using a stronger modulation or route.

Duty cycling, local aggregation, adaptive sampling, wake-up radios, energy-aware routing, and edge processing can extend lifetime. Nevertheless, reducing communication is not always optimal: local computation may itself be expensive, and aggressive sleep schedules can increase latency and packet loss. Energy objectives should therefore be defined against useful service, such as energy per correctly classified event or energy per delivered control action.

Scalability

Scalability concerns how performance and dependability change as the number of devices, message rate, geographic area, data volume, or administrative domains increase. Horizontal scaling of cloud services does not automatically solve wireless contention, gateway bottlenecks, address management, certificate validation, firmware distribution, or human maintenance capacity.

A scalability experiment should vary more than node count. It should examine density, traffic burstiness, topology, mobility, failure rate, edge placement, and control-plane overhead. Scaling can also create emergent risks: synchronized firmware updates may generate a traffic surge, while a common cloud dependency can create a large correlated failure domain.

Availability, Reliability, and Fault-Tolerant Design

For a repairable component with mean time between failures (MTBF) and mean time to repair (MTTR), a simple steady-state availability estimate is

A ≈ MTBF / (MTBF + MTTR).

This relation is useful but limited. It assumes stable rates and does not represent common-cause failures, degraded service, maintenance logistics, or dependencies. Series systems, in which every component is required, have lower availability as components are added. Parallel redundancy can improve availability when redundant units fail independently and switching is reliable. Independence must not be assumed when devices share a power supply, firmware defect, radio channel, cloud region, or physical location.

Reliability functions may be modeled through failure distributions. The exponential model assumes a constant hazard rate, whereas Weibull models can represent early-life defects, useful-life behavior, and wear-out. Reliability block diagrams describe structural relationships; fault-tree analysis starts with a hazardous top event and identifies combinations of causes; event-tree analysis explores consequences of initiating events. Markov and semi-Markov models are useful for systems that move among operational, degraded, failed, and repaired states.

Fault tolerance may be achieved through redundancy, diversity, isolation, graceful degradation, checkpointing, replication, retransmission, coding, watchdogs, and recovery procedures. Redundancy can be spatial, temporal, informational, or functional. For example, two temperature sensors provide spatial redundancy, repeated measurements provide temporal redundancy, and independent sensing modalities provide functional diversity.

A robust design defines degraded modes explicitly. If a cloud service is unreachable, an edge controller may continue local safety rules. If a noncritical sensor fails, the system may report reduced confidence rather than silently presenting stale data as current. If a gateway is overloaded, it may preserve emergency traffic while postponing bulk telemetry. Graceful degradation is not simply “keep running”; it is the controlled preservation of prioritized system functions.

Quality of Service and Real-Time Behavior

IoT QoS is multidimensional. It may include latency, reliability, packet-loss rate, jitter, freshness, availability, accuracy, energy use, and priority. A service-level objective should specify the metric, population, time window, workload, and measurement point. For instance, a 99th-percentile latency requirement at the application endpoint differs substantially from a radio-layer average delay.

Hard real-time systems must meet deadlines, while soft real-time systems tolerate some deadline misses with reduced utility. Firm real-time results become useless after a deadline, even if late delivery is not dangerous. Schedulability analysis can determine whether tasks meet deadlines under assumed execution times and priorities. Worst-case response-time analysis is stronger than average-case benchmarking, but it depends on credible bounds for computation, communication, interference, and recovery.

Wireless behavior complicates real-time guarantees because channel access, interference, retransmission, and route changes are probabilistic. Deterministic techniques include time-sensitive scheduling, bounded queues, admission control, traffic shaping, time synchronization, and reserved resources. When strict guarantees cannot be justified, the system should use probabilistic contracts, safety margins, monitoring, and explicit fail-safe behavior rather than making unsupported claims.

A Research and Engineering Workflow

Performance and resilience claims require a disciplined evidence chain.

First, define the mission, stakeholders, operating environment, failure assumptions, and service priorities. Identify which functions are safety-critical, time-critical, energy-critical, or privacy-sensitive. Second, formulate measurable requirements and acceptance criteria. Third, build an abstract model to expose bottlenecks and structural weaknesses. Fourth, implement simulation or emulation using realistic traffic, mobility, interference, and failures. Fifth, verify important properties formally where feasible. Sixth, construct a prototype or testbed and measure it under controlled and field conditions. Finally, compare evidence with requirements and revise the architecture.

Simulation is valuable for exploring large deployments and rare combinations of events. Discrete-event simulators represent packets, queues, and protocol actions; agent-based models represent autonomous nodes and human or environmental actors; hybrid models combine continuous physical dynamics with discrete communication events. Trace-driven simulation can replay real traffic, radio conditions, or failure patterns. Simulation results are conditional on the model and must not be presented as field truth without validation.

Formal methods address properties that testing may miss. Model checking can examine finite-state protocol models for deadlock, reachability, invariants, and temporal-logic requirements. Timed automata can represent deadlines and clock constraints. Probabilistic model checking can analyze reliability or deadline probabilities. The challenge is state-space explosion and abstraction validity. Formal proof of an abstract model does not prove the deployed system unless the abstraction faithfully preserves the property of interest.

Testing should combine unit, integration, interoperability, load, stress, endurance, fault-injection, recovery, security, and field testing. Network emulation can introduce controlled delay, loss, jitter, bandwidth limits, and disconnections. Hardware-in-the-loop testing exposes timing and power behavior hidden by software-only experiments. Chaos engineering applies controlled disruption to test recovery, but it must be bounded by safety controls and authorization.

Measurement requires instrumentation that does not substantially alter the system. Time synchronization, calibrated sensors, packet identifiers, distributed tracing, power monitors, and event logs support causal analysis. Experiments should state the hardware and firmware versions, radio configuration, topology, workload, environmental conditions, random seeds, warm-up period, repetitions, and statistical treatment. Report distributions and confidence intervals, not only a single average. Reproducibility also requires publishing configurations, code, datasets where lawful, and known limitations.

Architecture Patterns for Resilient IoT

A resilient architecture commonly separates device, edge, network, platform, and application concerns while retaining local autonomy for essential functions. Edge processing reduces backhaul traffic and can lower latency, but it introduces additional nodes that require updates, monitoring, physical protection, and trustworthy state management.

Useful patterns include local control loops, replicated gateways, multi-path communication, store-and-forward buffering, eventual synchronization, quorum-based decisions, and priority-aware admission control. A control loop should not depend on an indefinitely available cloud connection when loss of connectivity could create physical danger. Store-and-forward is appropriate for delay-tolerant telemetry but not for urgent actuation.

Observability is a resilience capability. Health indicators, heartbeats, quality estimates, battery state, queue depth, clock status, and model confidence enable early detection. However, monitoring itself consumes bandwidth and energy and can become a failure amplifier during an incident. Adaptive monitoring and hierarchical aggregation are often preferable.

Security and resilience are inseparable. Authentication prevents unauthorized participation, integrity protects commands and measurements, and secure update mechanisms reduce persistent compromise. Yet security controls must be included in performance and availability analysis. Certificate validation, key rotation, intrusion detection, and recovery from key compromise require computation, storage, connectivity, and governance. A system that is secure but cannot deliver a safety command within its deadline is not operationally adequate.

Applied Case: Resilient Cold-Chain Monitoring

Background

The following is an illustrative case. A pharmaceutical distributor operates refrigerated vehicles carrying temperature-sensitive products. Battery-powered sensors periodically measure temperature, door state, battery level, and location. A gateway forwards data through cellular and short-range wireless links to an operations platform.

Situation and problem

The original design transmitted every reading to the cloud. During a route through a region with intermittent cellular coverage, the gateway disconnected, buffers filled, and several temperature excursions were identified only after reconnection. The organization also discovered that frequent transmissions reduced sensor lifetime and that an alarm storm could delay the most important messages.

The requirements were differentiated. Temperature safety alarms had to be detected locally and communicated promptly when a path was available. Routine measurements could be delayed and compressed. The system had to preserve evidence of excursions, tolerate gateway disconnection, and avoid falsely declaring a shipment safe when data were stale.

Analysis

A latency model separated sensing interval, local rule evaluation, radio access, gateway queueing, cellular transmission, platform processing, and operator notification. A queueing analysis showed that routine telemetry consumed most of the uplink during reconnection bursts. A reliability block model identified the cellular link as a dominant availability dependency, while common power failure affected both gateway and sensors. Fault-tree analysis identified missed excursion detection as a top event caused by sensor failure, exhausted battery, software lockup, full buffer, clock error, or inadequate alarm logic.

Approach

The redesigned system used local threshold and rate-of-change rules, redundant temperature sensing at critical locations, prioritized alarm packets, persistent store-and-forward storage, and bounded backoff after reconnection. Routine readings were aggregated at the gateway, while alarm records included timestamps, sensor identity, calibration status, and confidence. The gateway maintained a local safety state and marked data as stale when synchronization exceeded a defined limit. A watchdog restarted failed processes, and a separate power monitor reported low-energy conditions.

Testing included packet loss, prolonged disconnection, clock drift, full storage, sensor disagreement, gateway reboot, cellular reconnection, and simultaneous alarm generation. Hardware-in-the-loop tests measured energy consumption and recovery time. Field trials compared latency distributions and battery use against the original design.

Outcome and learning points

The principal improvement was not a single faster protocol. It was the separation of essential local decisions from delay-tolerant reporting. Prioritization protected alarms during congestion, while buffering preserved evidence during outages. Sensor disagreement caused a diagnostic state rather than silent acceptance of one value. The case demonstrates that resilience depends on requirements, architecture, failure semantics, observability, and operational procedures together.

Challenges, Limitations, and Common Errors

A frequent mistake is optimizing mean latency while ignoring tail latency and deadline misses. Another is reporting packet delivery at the radio interface rather than successful, timely application service. Battery studies often omit energy used during discovery, security handshakes, firmware updates, and recovery. Availability calculations commonly assume independent failures even when components share infrastructure.

Models may be precise but wrong because environmental variability, human behavior, maintenance delays, or adversarial action was excluded. Conversely, field measurements may be realistic but too narrow to establish generality. Researchers should state assumptions, conduct sensitivity analysis, and distinguish internal validity from external validity.

Resilience can also conflict with safety. Automatic failover may move control to a replica with stale state. Aggressive recovery may repeatedly restart a component and amplify congestion. Redundancy may create conflicting actuator commands. Every recovery mechanism requires authority boundaries, consistency rules, rate limits, and a safe stopping condition.

Ethically, monitoring systems must not conceal uncertainty or silently trade individual safety for aggregate efficiency. Data retention, location tracking, worker monitoring, and automated decisions require purpose limitation, access control, transparency, and appropriate oversight. Regulatory obligations may apply to medical, transport, industrial, environmental, or critical-infrastructure deployments. Audit trails should record who changed requirements, models, firmware, and operational policies.

Current Developments and Best Practices

Digital twins are increasingly used to connect physical assets, operational data, and simulation models. Their value depends on calibration and uncertainty representation; a visually impressive twin is not evidence of predictive accuracy. Machine learning can forecast failures, classify anomalies, and optimize sampling, but model drift, biased training data, false alarms, adversarial manipulation, and unexplained decisions require governance. A predictive-maintenance model should be evaluated not only by classification accuracy but also by intervention cost, missed failures, energy use, and safety impact.

Emerging wireless systems offer improved integration of edge computing, deterministic scheduling, sensing and communication, and non-terrestrial connectivity. These capabilities expand design options but do not remove fundamental concerns about interference, failure independence, timing, energy, and maintainability.

Best practice is to:

• define service levels by mission and priority rather than by a single average metric;
• analyze end-to-end behavior, including queues, dependencies, recovery, and human response;
• measure percentiles, deadline misses, energy per useful service, and degraded-mode behavior;
• test realistic interference, mobility, outages, aging, updates, and correlated failures;
• combine simulation, formal reasoning, fault injection, prototypes, and field evidence;
• design local safe behavior for loss of connectivity and explicitly label stale or uncertain data;
• treat observability, secure updates, configuration control, and maintenance as engineering functions;
• document assumptions, uncertainty, reproducibility artifacts, and residual risk.

Chapter Summary

Performance and resilience in IoT are multidimensional system properties. Latency, throughput, jitter, energy, availability, reliability, scalability, QoS, and real-time behavior must be analyzed together because improvements in one dimension can damage another. Useful engineering begins with measurable mission requirements and proceeds through models, simulation, formal analysis, testing, and empirical measurement. Queueing and latency models reveal congestion; reliability and availability models expose dependencies; energy models support lifetime decisions; fault trees, reliability blocks, Markov models, and timed analysis support dependability reasoning.

Resilient IoT architectures use prioritization, redundancy, diversity, isolation, local autonomy, buffering, graceful degradation, observability, secure recovery, and explicit failure semantics. No model or test is sufficient alone. Credible conclusions require stated assumptions, realistic workloads, uncertainty analysis, reproducibility, and field validation. Finally, resilience is both a technical and governance concern: safety, privacy, accountability, maintenance, and ethical treatment of uncertainty must remain part of system design.

Key Terms

Reliability: Probability that a system performs its required function without failure for a specified time and conditions.

Availability: Probability that a service is operational when required.

Dependability: Collective ability to deliver trusted service, including reliability, availability, safety, and maintainability.

Resilience: Capacity to withstand, adapt to, recover from, and learn from disruption.

Survivability: Ability to preserve essential functions under severe or hostile conditions.

Fault: A hypothesized cause of an incorrect system state.

Error: An incorrect internal state produced when a fault is activated.

Failure: Deviation of delivered service from specified requirements.

Fault tolerance: Ability to provide acceptable service despite faults.

Latency: Time between an initiating event and the corresponding observed response.

Jitter: Variation in latency or timing.

Throughput: Rate of data or work processed by a system.

Goodput: Rate of useful application data delivered after overhead and losses.

MTBF: Mean time between failures for a repairable or recurring system.

MTTR: Mean time required to restore service after failure.

QoS: Set of measurable service characteristics such as delay, loss, reliability, and priority.

Graceful degradation: Controlled reduction of service while preserving essential functions.

Fault-tree analysis: Deductive analysis from a hazardous top event to combinations of causes.

Deadline miss ratio: Proportion of tasks or messages completed after their required deadlines.

Store-and-forward: Technique that buffers data during disconnection and transmits it when connectivity returns.

Review Questions

Short Answer Questions

1. Distinguish reliability from availability in a repairable IoT system.

2. Why can goodput be more informative than nominal wireless throughput?

3. What is the difference among a fault, an error, and a failure?

4. Explain why tail latency matters in real-time IoT applications.

5. Identify two limitations of the simple MTBF–MTTR availability model.

Long Answer Questions

1. Explain how an end-to-end latency model can be constructed for an edge-enabled IoT control loop.

2. Compare simulation, formal verification, testing, and empirical measurement as sources of evidence.

3. Discuss architectural techniques for graceful degradation and local autonomy.

4. Analyze the relationship among QoS, energy consumption, scalability, and reliability.

5. Explain how fault-tree analysis, reliability block diagrams, and Markov models support dependability engineering.

Analytical / Application Questions

1. An IoT network operates close to channel capacity and experiences alarm bursts. Propose a measurement and redesign strategy that protects critical traffic while preserving routine telemetry.

2. Design a failure model for a connected industrial controller that loses cloud connectivity but must maintain safe local operation. State assumptions, degraded modes, and validation methods.

3. Evaluate whether a machine-learning predictive-maintenance system should be deployed when it reduces false alarms but occasionally misses rare catastrophic failures. Identify the additional evidence and governance controls required.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes availability from reliability?

A. Availability concerns whether service is operational when needed, whereas reliability concerns failure-free operation over a specified period.

B. Availability measures only energy consumption, whereas reliability measures bandwidth.

C. Availability applies only to wireless links, whereas reliability applies only to software.

D. Availability and reliability are identical for all repairable systems.

Correct Answer: A. Availability concerns whether service is operational when needed, whereas reliability concerns failure-free operation over a specified period.

Question 2

A system has an arrival rate that approaches its service capacity. Which result is most likely in a basic queueing model?

A. Queueing delay decreases toward zero.

B. Queueing delay increases sharply.

C. Energy consumption becomes independent of traffic.

D. Packet reliability becomes exactly 100 percent.

Correct Answer: B. Queueing delay increases sharply.

Question 3

Why is goodput often preferable to nominal data rate when evaluating an IoT link?

A. It excludes useful application data.

B. It measures only propagation delay.

C. It accounts for overhead, retransmissions, and successfully delivered useful data.

D. It assumes that all packets are delivered once.

Correct Answer: C. It accounts for overhead, retransmissions, and successfully delivered useful data.

Question 4

Which design most directly supports graceful degradation during cloud disconnection?

A. Require every actuator decision to await cloud confirmation.

B. Disable all local processing to avoid inconsistent state.

C. Use local safety rules while buffering delay-tolerant telemetry.

D. Increase routine telemetry frequency during the outage.

Correct Answer: C. Use local safety rules while buffering delay-tolerant telemetry.

Question 5

In dependability analysis, what is the relationship among fault, error, and failure?

A. A fault is a cause, an error is an incorrect internal state, and a failure is incorrect delivered service.

B. A fault is always visible to users, while an error is always harmless.

C. A failure causes a fault, which then creates an error.

D. The three terms describe identical events at different network layers.

Correct Answer: A. A fault is a cause, an error is an incorrect internal state, and a failure is incorrect delivered service.

Question 6

Why can adding redundant components fail to improve availability as much as expected?

A. Redundancy always increases MTTR to infinity.

B. Redundant components may share common causes such as power, software, or location.

C. Parallel components cannot be monitored.

D. Redundancy eliminates the need for recovery mechanisms.

Correct Answer: B. Redundant components may share common causes such as power, software, or location.

Question 7

Which experiment best evaluates resilience of a gateway-based IoT system?

A. Measure only average packet size under ideal laboratory conditions.

B. Test disconnection, buffer exhaustion, reboot, reconnection, and prioritized recovery.

C. Count the number of installed sensors without generating traffic.

D. Measure cloud CPU utilization while all gateways are disabled.

Correct Answer: B. Test disconnection, buffer exhaustion, reboot, reconnection, and prioritized recovery.

Question 8

For a hard real-time IoT task, which metric is most appropriate?

A. Average payload size only.

B. Maximum acceptable battery voltage only.

C. Deadline compliance under specified worst-case assumptions.

D. Number of cloud dashboards available.

Correct Answer: C. Deadline compliance under specified worst-case assumptions.

Question 9

What is a principal risk of reporting only mean latency?

A. It may hide rare but operationally important tail delays.

B. It always overestimates the maximum latency.

C. It prevents measurement of throughput.

D. It guarantees that jitter is zero.

Correct Answer: A. It may hide rare but operationally important tail delays.

Question 10

Which approach provides the strongest basis for a credible performance claim?

A. A single simulation using undocumented assumptions.

B. A vendor data sheet without field validation.

C. Combining models, controlled tests, empirical measurements, and stated uncertainty.

D. An average obtained from one short trial under ideal conditions.

Correct Answer: C. Combining models, controlled tests, empirical measurements, and stated uncertainty.