System Modeling and Hardware–Software Co-Design

Introduction and Context

Embedded systems combine computation, communication, sensing, actuation, and physical processes under constraints that are usually more severe than those of general-purpose computers. A design must not only produce correct results; it must meet deadlines, fit within memory and energy budgets, tolerate faults, remain maintainable, and often satisfy safety or regulatory requirements. These properties are determined jointly by the system’s algorithm, architecture, hardware platform, software structure, and operating environment.

System modeling provides abstractions that allow engineers to reason about behavior before committing to implementation. Hardware–software co-design extends this idea by treating hardware and software as alternative implementation resources and optimizing their allocation simultaneously. Instead of asking whether a function is “hardware” or “software” by habit, the designer evaluates alternatives against timing, cost, energy, flexibility, verification effort, and lifecycle considerations.

A useful co-design process therefore moves through several abstraction levels: requirements, behavioral models, architecture, partitioning, implementation, verification, and deployment. Errors discovered at a higher level are generally cheaper to correct than errors discovered after fabrication or field deployment.

Learning Objectives

After completing this chapter, the learner should be able to:

1. Select appropriate finite-state, data-flow, object-oriented, and hybrid models for embedded behavior.

2. Construct and analyze finite-state machines and data-flow graphs.

3. Explain the roles of UML, SysML, and model-based design in embedded development.

4. Formulate hardware–software partitioning as a constrained design-space exploration problem.

5. Evaluate alternatives using timing, cost, power, reliability, and maintainability criteria.

6. Apply practical co-design methods to a representative embedded-system case.

7. Identify limitations, verification risks, governance obligations, and emerging trends.

1. Abstraction and System Models

A model is a purposeful representation of a system. It suppresses details that are irrelevant to a particular question while preserving properties needed for analysis. No single model adequately represents all aspects of an embedded system.

A structural model describes components and relationships: processors, memories, buses, sensors, tasks, and interfaces. A behavioral model describes how the system responds to inputs and evolves over time. A deployment model maps logical functions to physical nodes. A performance model represents execution time, communication delay, throughput, and resource usage. A power model estimates dynamic and static energy or power under operating conditions.

Model fidelity and model complexity must be balanced. An executable model can support simulation and automatic code generation, but it may introduce assumptions that hide hardware effects. Conversely, a register-transfer-level model can expose implementation detail but is costly to construct and unsuitable for early requirements reasoning.

Important terminology

• State: A condition containing the information necessary to determine future behavior.
• Event: An occurrence that may cause a transition or trigger computation.
• Guard: A Boolean condition controlling whether a transition is enabled.
• Action: An operation performed during a transition or state activity.
• Task: A schedulable unit of software execution.
• Token: A data item flowing through a data-flow graph.
• Actor: A computation that consumes and produces tokens.
• Model of computation: Formal rules defining time, communication, concurrency, and execution.
• Partitioning: Assignment of functions to hardware or software resources.
• Design-space exploration (DSE): Systematic evaluation of alternative architectures and implementations.
• Traceability: Ability to relate requirements to models, implementation, and verification evidence.

2. Finite-State Machines

A finite-state machine (FSM) models behavior as a finite set of states and transitions. A deterministic FSM may be represented as

\[

M=(S, I, O, \delta, \lambda, s_0),

\]

where \(S\) is the finite state set, \(I\) the input alphabet, \(O\) the output alphabet, \(\delta:S\times I\rightarrow S\) the transition function, \(\lambda\) the output function, and \(s_0\) the initial state. The notation assumes discrete events and a finite representation of relevant history.

In a Moore machine, output depends only on the current state:

\[

\lambda:S\rightarrow O.

\]

In a Mealy machine, output depends on current state and input:

\[

\lambda:S\times I\rightarrow O.

\]

Mealy machines can respond immediately to an input, whereas Moore machines often provide simpler and more stable output behavior. In hardware control logic, the choice affects latency, output glitches, and state encoding.

Consider a controller for a motor with states `IDLE`, `STARTING`, `RUNNING`, and `FAULT`. A transition from `STARTING` to `RUNNING` may have guard `speed_ok ∧ current_ok`; a transition from any active state to `FAULT` may be triggered by `overcurrent`. The model should specify what happens when events occur simultaneously, whether transitions have priority, and whether recovery from `FAULT` requires operator acknowledgement.

FSM design issues

State explosion occurs when many independent conditions are represented by one monolithic machine. Hierarchical state machines reduce this problem by allowing states to contain substates. Orthogonal regions model concurrent behavior, while history states preserve selected prior configuration. These extensions improve readability but require precise semantics for concurrency and event priority.

FSMs are well suited to protocol controllers, user interfaces, startup sequences, safety interlocks, and mode management. They are less suitable for intensive numerical algorithms or systems with unbounded data structures. Such functionality is usually represented by data-flow or algorithmic models and coordinated by an FSM.

FSM validation should include reachability analysis, dead-state detection, transition coverage, guard completeness, illegal-event analysis, and checks for livelock. Safety properties can often be expressed as invariants, such as “the actuator is never enabled while the guard is open.”

3. Data-Flow and Time-Oriented Models

A data-flow graph (DFG) represents computation as actors connected by directed edges. Actors consume input tokens, perform operations, and produce output tokens. For a streaming signal-processing chain, a graph might contain sampling, filtering, feature extraction, classification, and communication actors.

Data-flow models make dependencies, concurrency, and throughput visible. In synchronous data flow (SDF), each actor consumes and produces a fixed number of tokens per firing. If actor \(i\) consumes \(c_i\) tokens and produces \(p_i\) tokens on an edge, a repetition vector can be found from balance equations. For an edge from actor \(i\) to actor \(j\),

\[

q_i p_i=q_j c_j,

\]

where \(q_i\) and \(q_j\) are the numbers of firings in one graph iteration. This equation assumes fixed production and consumption rates and a consistent, bounded graph. A valid repetition vector supports buffer sizing, scheduling, and throughput analysis.

For example, actor A produces 2 tokens per firing and actor B consumes 3 tokens per firing. The smallest positive integer solution to \(2q_A=3q_B\) is \(q_A=3\), \(q_B=2\). Thus three firings of A supply six tokens, consumed by two firings of B.

A useful upper-bound estimate for a sequential pipeline is

\[

T_{\text{iteration}}\approx \sum_i t_i + \sum_k d_k,

\]

where \(t_i\) are actor execution times and \(d_k\) are communication delays. This is not a general throughput equation: in a concurrent pipeline, the steady-state period may instead be constrained by the slowest stage and resource conflicts. The approximation is applicable only when operations execute sequentially in the assumed order.

Other models include:

• Kahn process networks: deterministic processes communicating through unbounded FIFO channels, useful for functional reasoning but requiring practical buffer bounds.
• Petri nets: places, transitions, and tokens representing synchronization and concurrency; particularly useful for deadlock and reachability analysis.
• Timed automata: finite-state behavior with clocks and timing constraints.
• Discrete-event models: systems evolve at event times rather than at fixed time steps.
• Hybrid models: combine discrete control with continuous physical dynamics.

Model selection should follow the dominant concern. FSMs clarify control, SDF clarifies streaming computation, Petri nets clarify synchronization, and hybrid models clarify cyber-physical interaction.

4. UML and SysML for Embedded Systems

The Unified Modeling Language (UML) provides standardized diagrams for structure and behavior. Class diagrams represent structural relationships; state-machine diagrams represent event-driven behavior; sequence diagrams represent interactions over time; activity diagrams represent workflows; and component diagrams represent replaceable units and interfaces.

For embedded engineering, UML is most effective when diagrams have unambiguous semantics and are linked to requirements and implementation. A sequence diagram for a sensor transaction, for example, should identify request timing, timeout behavior, retries, and error responses rather than merely show nominal message order.

SysML extends UML for systems engineering. It supports requirements diagrams, block definition diagrams, internal block diagrams, activity diagrams, state machines, parametric diagrams, and allocation relationships. A parametric model can relate battery energy, processor load, and mission duration; an allocation relationship can map a logical function to a microcontroller, FPGA region, or software task.

Neither UML nor SysML automatically guarantees real-time correctness. Diagrammatic models must be supplemented with execution semantics, timing annotations, resource assumptions, interface contracts, and verification evidence. Profiles such as MARTE can add real-time and embedded-system concepts, but tool compatibility and semantic variation remain practical concerns.

5. Model-Based Design and Refinement

Model-based design (MBD) uses an executable model as a central engineering artifact. A typical workflow is:

1. Capture requirements and assumptions.

2. Build a functional model independent of target hardware.

3. Simulate nominal, boundary, and fault scenarios.

4. Refine the model with timing, communication, and resource information.

5. Partition functions between hardware and software.

6. Generate or manually implement code and hardware descriptions.

7. Verify equivalence or acceptable conformance at successive abstraction levels.

8. Perform hardware-in-the-loop, processor-in-the-loop, and system-level tests.

A refinement is valid only if the lower-level implementation preserves the properties required at the higher level. Exact mathematical equivalence may be impossible when quantization, scheduling, interrupts, or sensor noise are introduced. Therefore, requirements should specify tolerances, deadlines, safety constraints, and permitted numerical error.

MBD supports rapid exploration and automatic code generation, but generated code is not automatically optimal, safe, or certifiable. Engineers must inspect numerical types, overflow behavior, initialization, scheduling, generated interfaces, and compiler-dependent effects. Configuration management must preserve the version of the model, toolchain, libraries, and generation settings used to produce each artifact.

6. Hardware–Software Partitioning

Partitioning assigns functions to implementation resources. Software offers flexibility, easier updates, and lower nonrecurring engineering cost. Hardware can provide deterministic latency, high parallelism, specialized interfaces, and improved energy efficiency for suitable workloads. A hardware accelerator may nevertheless increase verification effort, board complexity, area, and energy at low utilization.

Partitioning criteria include:

• Timing: worst-case execution time, latency, jitter, throughput, and deadline miss probability.
• Energy and power: active energy, leakage, memory movement, and peak power.
• Cost: component cost, FPGA or ASIC area, development cost, and production volume.
• Flexibility: updateability, parameter changes, and algorithm evolution.
• Reliability and safety: fault containment, diagnostic coverage, and determinism.
• Maintainability: readability, tool availability, personnel skills, and testability.
• Security: attack surface, isolation, secure boot, and protection of keys.

A simple allocation model can be written as a constrained optimization problem:

\[

\min_{x\in X} J(x)=w_T\hat T(x)+w_E\hat E(x)+w_C\hat C(x)+w_M\hat M(x),

\]

subject to

\[

T(x)\leq T_{\max},\quad E(x)\leq E_{\max},\quad C(x)\leq C_{\max}.

\]

Here, \(x\) denotes an allocation and implementation choice; \(\hat T,\hat E,\hat C,\hat M\) are normalized metrics; \(w_T,w_E,w_C,w_M\) are nonnegative decision weights; and \(J\) is meaningful only when normalization and stakeholder priorities are explicitly defined. The model does not imply that all objectives are truly commensurate. A Pareto analysis is often preferable: an alternative is Pareto-dominated if another is no worse in every criterion and strictly better in at least one.

Communication must be included in partitioning decisions. If a software task invokes an accelerator, total latency can be approximated as

\[

T_{\text{total}}=T_{\text{setup}}+T_{\text{transfer,in}}+T_{\text{compute}}+T_{\text{transfer,out}}+T_{\text{sync}}.

\]

This equation assumes sequential, non-overlapped phases. DMA, double buffering, bus contention, and concurrent execution can reduce or alter the actual latency, so the terms must be measured or conservatively bounded.

Design-space exploration

DSE evaluates combinations of processor type, clock frequency, memory organization, accelerator selection, bus architecture, task mapping, and scheduling policy. Exhaustive search may be feasible for small spaces but becomes impractical as choices multiply. Common strategies include:

• pruning alternatives that violate hard constraints;
• analytical performance and power estimation;
• simulation and trace-driven evaluation;
• integer or mixed-integer optimization for discrete choices;
• genetic algorithms, simulated annealing, or Bayesian optimization for large spaces;
• Pareto-frontier inspection rather than one weighted score;
• sensitivity analysis to identify assumptions that most affect the decision.

A credible DSE process reports uncertainty. Execution-time estimates should identify whether they are average, percentile, or worst-case values. Hardware measurements should specify clock, voltage, data distribution, compiler, and temperature. Optimizing a nominal benchmark can produce a design that fails under realistic workloads.

7. Timing, Scheduling, and Verification

A co-designed system must satisfy both functional and temporal requirements. Average execution time is insufficient for hard real-time systems. Worst-case execution time (WCET), blocking, interrupt interference, cache behavior, bus contention, and scheduling overhead must be considered.

For independent periodic tasks scheduled on a single preemptive fixed-priority processor, a commonly used response-time recurrence is

\[

R_i=C_i+B_i+\sum_{j\in hp(i)}\left\lceil\frac{R_i}{T_j}\right\rceil C_j,

\]

where \(R_i\) is the response-time bound of task \(i\), \(C_i\) its WCET, \(B_i\) blocking time, \(T_j\) the period of higher-priority task \(j\), and \(hp(i)\) the set of higher-priority tasks. The recurrence is solved iteratively from \(R_i^{(0)}=C_i+B_i\). It assumes a specified fixed-priority preemptive model and conservative WCET values; it is not directly applicable to arbitrary multicore or non-preemptive systems.

Verification should occur at multiple levels:

• requirement consistency and completeness;
• model simulation and property checking;
• formal reachability or invariant analysis for control logic;
• unit, integration, and interface testing;
• processor-in-the-loop and hardware-in-the-loop testing;
• fault injection and robustness testing;
• timing, power, thermal, and electromagnetic validation;
• traceability from requirement to test evidence.

Co-simulation is valuable when hardware and software models evolve at different rates. However, mismatched time steps, abstract communication channels, and idealized peripherals can conceal integration defects. A model’s assumptions must therefore be treated as verification obligations.

8. Illustrative Case: Wearable Cardiac-Monitoring Node

This is an illustrative engineering case, not a clinical product specification.

Background

A wearable node samples an electrocardiographic signal, detects candidate cardiac events, stores a short waveform, and transmits selected events to a gateway. The design must operate for several days from a small battery, respond promptly to abnormal patterns, and permit algorithm updates.

Problem

A purely software implementation on a low-power microcontroller is flexible but consumes substantial energy during continuous filtering and feature extraction. A fully custom ASIC would be efficient but costly to change and difficult to validate for an evolving algorithm. The design team must determine which functions to accelerate and how to preserve maintainability.

Analysis

The behavioral model contains an FSM with states `SLEEP`, `SAMPLE`, `ANALYZE`, `STORE_EVENT`, `TRANSMIT`, and `FAULT`. A data-flow graph represents sampling, band-pass filtering, peak detection, feature extraction, and classification. Requirements include a sampling rate, an analysis deadline, bounded event-storage latency, and a minimum battery-life target. These values would be supplied by the product and clinical requirements process.

Profiling shows that filtering and peak detection dominate processor cycles, while classification changes frequently as algorithms are improved. Communication is bursty and energy-intensive, so transmitting every sample is undesirable. The team evaluates three alternatives: all-software; a fixed-function filter accelerator; and a programmable DSP/FPGA-style accelerator with DMA.

Approach and solution

The team selects a small fixed-function filtering accelerator for the stable, high-duty-cycle operation and retains feature extraction and classification in software. The accelerator accepts buffered samples through DMA, reducing processor intervention. The FSM controls power states and rejects transmission when battery or link policies prohibit it. Double buffering permits one block to be processed while the next is acquired, but the timing model explicitly includes buffer-switching and bus contention.

The design-space study compares energy per sample, worst-case analysis latency, silicon or programmable-logic area, firmware complexity, and update cost. A Pareto analysis shows that the hybrid solution meets the timing and energy constraints without locking the evolving classifier into hardware.

Outcome

The principal outcome is not merely lower computation time. The partition also creates a clear verification boundary: the accelerator is verified against a numerical reference model, while the classifier is tested with recorded and synthetic waveforms. Requirements, model states, generated interfaces, and test cases are linked through traceability records.

Learning points

1. The most computationally expensive function is not automatically the best hardware candidate; stability and communication overhead matter.

2. Buffering and data movement can dominate accelerator benefits.

3. A hierarchical FSM clarifies power management and fault recovery.

4. Keeping evolving algorithms in software can reduce lifecycle cost.

5. For health-related products, performance evidence must be accompanied by risk management, cybersecurity, privacy controls, and applicable medical-device compliance activities.

9. Professional, Ethical, and Governance Considerations

Co-design decisions can create safety and social consequences. An optimization that reduces cost by removing diagnostics may increase unacceptable risk. A model that assumes perfect sensors may produce unsafe control behavior. Engineers should document assumptions, uncertainties, rejected alternatives, and residual risks.

Safety-related systems require hazard analysis, independence of verification where appropriate, controlled configuration, and evidence proportional to risk. Relevant standards depend on domain and jurisdiction; examples include functional-safety, avionics, automotive, industrial, and medical-device frameworks. Standards should be consulted in their current versions rather than treated as interchangeable checklists.

Security must be modeled early. Hardware roots of trust, secure boot, memory protection, isolation, authenticated updates, key management, and fault logging affect the architecture. Privacy is particularly important for wearable, domestic, and connected devices. Data minimization, access control, retention limits, and transparent consent should influence communication and storage design.

Artificial intelligence may be included as a software function, accelerator workload, or adaptive component. Its use introduces dataset quality, distribution shift, explainability, monitoring, and update-control issues. An AI model’s average accuracy does not establish real-time safety or robustness. Hardware–software co-design should therefore include inference latency, memory footprint, numerical quantization, adversarial resilience, and post-deployment monitoring.

10. Contemporary Developments and Best Practices

Current embedded platforms increasingly combine heterogeneous CPU cores, DSPs, GPUs, neural-processing units, programmable logic, and secure enclaves. This increases performance potential but makes timing, memory coherence, toolchain support, and verification more difficult. Chiplet-based integration, open instruction sets, edge AI, digital twins, and virtual prototypes are expanding the design space.

Effective practice includes:

• begin with explicit, testable requirements;
• use multiple complementary models rather than one universal diagram;
• distinguish functional correctness from timing and resource correctness;
• include communication, memory movement, and synchronization in cost models;
• explore Pareto-optimal alternatives before selecting weights;
• use measured data to calibrate analytical models;
• maintain bidirectional traceability;
• make assumptions and uncertainty visible;
• design interfaces and partition boundaries for verification;
• preserve software update and diagnostic paths;
• review safety, security, privacy, and regulatory obligations early;
• re-run DSE when workloads, technologies, or requirements change.

Challenges and Limitations

Model abstraction can hide cache effects, analog behavior, compiler transformations, bus contention, thermal throttling, and fault modes. Automatic code generation can amplify a modeling error across an entire product. DSE results are only as reliable as the estimators and workloads used. Weighted objectives may conceal stakeholder disagreement, while Pareto sets may be too large to decide without qualitative judgment.

Hardware–software boundaries are also organizational boundaries. Separate teams may optimize local metrics while degrading system performance. Successful co-design requires shared interfaces, common configuration control, compatible verification environments, and communication between algorithm, hardware, firmware, safety, and product teams.

Chapter Summary

System modeling provides disciplined abstractions for understanding embedded structure, behavior, timing, communication, and deployment. Finite-state machines are effective for control and mode management; data-flow models expose concurrency, token dependencies, throughput, and buffering; Petri nets, timed automata, and hybrid models address synchronization and cyber-physical behavior. UML and SysML organize requirements, structure, behavior, allocation, and parametric relationships, but require precise execution semantics and verification evidence.

Model-based design supports simulation, refinement, traceability, and selective automation. Hardware–software co-design treats allocation as a constrained multi-objective problem involving timing, energy, cost, flexibility, safety, security, and maintainability. Communication overhead and memory movement must be included in accelerator evaluations. Design-space exploration, Pareto analysis, calibrated estimation, and multi-level verification help manage complexity. The illustrative wearable-monitoring case demonstrates why hybrid partitioning often balances efficiency with algorithmic flexibility. Finally, trustworthy embedded systems require explicit assumptions, lifecycle governance, cybersecurity, privacy, and domain-appropriate safety evidence.

Key Terms

Model: A purposeful abstraction of a system used for analysis, communication, or implementation.

Finite-state machine: A model with finite states, inputs, outputs, and transition rules.

Moore machine: An FSM whose output depends only on its current state.

Mealy machine: An FSM whose output depends on its current state and input.

Guard: A Boolean condition that enables or disables a transition.

Data-flow graph: A graph of actors and directed data dependencies.

Synchronous data flow: A data-flow model with fixed token production and consumption rates.

Petri net: A token-based model for concurrency, synchronization, and reachability analysis.

UML: A standardized language for modeling software and system structure and behavior.

SysML: A systems-engineering modeling language extending UML concepts.

Model-based design: Development organized around executable and refinable system models.

Partitioning: Assignment of system functions to hardware or software resources.

Design-space exploration: Systematic evaluation of architectural and implementation alternatives.

Pareto frontier: Set of alternatives not dominated across the selected objectives.

WCET: A conservative upper bound on a task’s execution time.

Traceability: Relationship linking requirements, design artifacts, implementation, and tests.

Hardware accelerator: Specialized hardware that performs selected computations efficiently.

Co-simulation: Joint execution of models representing different parts or abstraction levels of a system.

Review Questions

Short Answer Questions

1. What distinguishes a Moore machine from a Mealy machine?

2. Why are data-flow models useful for streaming embedded applications?

3. Define hardware–software partitioning.

4. What is meant by a Pareto-dominated design?

5. Why must communication overhead be included when evaluating an accelerator?

Long Answer Questions

1. Explain how FSMs, data-flow graphs, and SysML complement one another in an embedded-system project.

2. Describe a model-based design workflow from requirements through hardware-in-the-loop verification.

3. Discuss the principal criteria used in hardware–software partitioning.

4. Explain the benefits and limitations of automatic code generation.

5. Discuss how safety, cybersecurity, privacy, and maintainability influence co-design decisions.

Analytical / Application Questions

1. A data-flow actor produces 4 tokens per firing and its consumer requires 6 tokens per firing. Determine the smallest positive integer firing counts that balance the edge, and explain the significance.

2. Propose a partition for a sensor-processing system containing sampling, filtering, classification, and wireless transmission. Justify your allocation using timing, energy, flexibility, and communication considerations.

3. Construct a hierarchical FSM for a battery-powered device with sleep, active, transmit, and fault modes. Identify at least two safety invariants and explain how you would verify them.

Multiple Choice Questions with Answers

Question 1

Which model is most directly suited to representing event-driven control modes and guarded transitions?

A. Finite-state machine

B. Synchronous data-flow graph

C. Cache-coherence protocol

D. Physical layout model

Correct Answer: A. Finite-state machine

Question 2

In a Moore machine, the output is determined by:

A. The next state only

B. The current state only

C. The current input only

D. The current state and input

Correct Answer: B. The current state only

Question 3

An actor produces 2 tokens per firing and its consumer consumes 3 tokens per firing. What is the smallest balanced firing pattern?

A. 2 producer firings and 3 consumer firings

B. 3 producer firings and 2 consumer firings

C. 3 producer firings and 3 consumer firings

D. 2 producer firings and 2 consumer firings

Correct Answer: B. 3 producer firings and 2 consumer firings

Question 4

Which SysML relationship is most directly used to show mapping of a logical function to a physical implementation resource?

A. Allocation

B. Generalization

C. Aggregation

D. Enumeration

Correct Answer: A. Allocation

Question 5

Which statement best describes a Pareto-optimal design?

A. It has the lowest value for every objective

B. It is not dominated by another evaluated design

C. It always has the lowest development cost

D. It is selected solely by weighted averaging

Correct Answer: B. It is not dominated by another evaluated design

Question 6

Which item is included in total accelerator latency but is often incorrectly omitted?

A. Only source-code length

B. Data transfer and synchronization time

C. The number of UML diagrams

D. The product marketing budget

Correct Answer: B. Data transfer and synchronization time

Question 7

What is the main purpose of a repetition vector in a synchronous data-flow graph?

A. To assign interrupt priorities

B. To determine balanced actor firing counts

C. To encrypt tokens

D. To calculate transistor leakage exactly

Correct Answer: B. To determine balanced actor firing counts

Question 8

Which metric is specifically a conservative upper bound on task execution time?

A. Average throughput

B. WCET

C. Code size

D. Battery capacity

Correct Answer: B. WCET

Question 9

Why might a frequently changing classification algorithm remain in software while filtering is implemented in hardware?

A. Software cannot be tested

B. Hardware cannot perform arithmetic

C. Software preserves update flexibility

D. Filtering never consumes computation time

Correct Answer: C. Software preserves update flexibility

Question 10

Which practice most improves confidence in a model-based co-design result?

A. Ignoring model assumptions

B. Using only nominal workloads

C. Calibrating models with measurements and maintaining traceability

D. Optimizing one local component independently

Correct Answer: C. Calibrating models with measurements and maintaining traceability