Computing and Computational Thinking for Engineers

Introduction

Electrical engineering systems increasingly combine physical components with computation. A motor drive may contain power semiconductor devices, sensors, a microcontroller, feedback-control software, and a communications interface. A protection relay must sample electrical quantities, estimate system conditions, and issue a trip command within a strict deadline. Even when computation is not visible to the user, software frequently determines system behavior.

Programming is therefore more than writing source code. Engineers must understand how instructions execute on hardware, how software layers interact, how problems are decomposed, and how algorithms transform inputs into outputs. They must also reason about timing, finite precision, resource limits, safety, security, and maintainability. These abilities form computational thinking: a disciplined approach to representing problems so that their solutions can be executed, tested, and evaluated systematically.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the roles of processors, memory, interconnects, and peripherals.
2. Distinguish software layers while recognizing that embedded architectures do not always form a strict hierarchy.
3. Compare major programming-language paradigms.
4. Define algorithms and evaluate correctness, efficiency, and resource use.
5. apply abstraction, decomposition, pattern recognition, and representation to engineering problems.
6. Express solutions using structured pseudocode and flowcharts.
7. Relate programming decisions to real-time electrical engineering systems.
8. Identify professional, ethical, safety, security, and governance responsibilities associated with software-controlled equipment.

1. Computers as Engineered Systems

A computer is a programmable system that accepts data, stores and transforms it according to instructions, and produces results. General-purpose computers emphasize flexibility, whereas embedded computers are designed for defined functions within products such as inverters, instruments, vehicles, medical devices, and protective relays.

1.1 Processor

The central processing unit (CPU) executes machine instructions. A typical CPU includes:

• an arithmetic and logic unit (ALU) for arithmetic, comparison, and Boolean operations;
• a control unit that fetches, decodes, and coordinates instruction execution;
• registers, which provide small, fast storage for operands, addresses, and processor state;
• a program counter, which identifies the next instruction;
• one or more execution units and, in many processors, caches and pipelines.

A simplified instruction cycle is:

1. Fetch an instruction from memory.
2. Decode its operation and operands.
3. Execute the operation.
4. Access memory, if required.
5. Write back the result.

Modern processors overlap these stages through pipelining, and actual execution may involve caches, branch prediction, interrupts, or parallel units. The cycle remains a useful conceptual model, but it should not be mistaken for a complete microarchitectural description.

1.2 Memory and storage

Computer storage forms a hierarchy. Registers are generally fastest and smallest. Cache memory retains recently or frequently used information near the processor. Random-access memory (RAM) stores active programs and data but is normally volatile. Non-volatile memory, such as flash memory, preserves programs and configuration data without power. Secondary storage provides larger persistent capacity where required.

The distinction between program memory and data memory may be physical, logical, or absent. In a Harvard architecture, instruction and data paths are separate; in a von Neumann architecture, instructions and data share an address space or path. Many contemporary processors use hybrid arrangements—for example, separate instruction and data caches connected to a unified main memory.

1.3 Interconnects and peripherals

Interconnects carry addresses, data, control information, requests, acknowledgements, and status between components. Individual signals may be unidirectional or bidirectional, but normal processor–memory and processor–peripheral operation involves information exchange in both logical directions. The processor may write a control register, while a peripheral may return measured data or status.

Peripherals connect computation to the physical or communication environment. Common examples include:

• general-purpose digital input/output (GPIO);
• timers and pulse-width modulation (PWM) units;
• analog-to-digital converters (ADCs);
• digital-to-analog converters (DACs);
• serial interfaces such as UART, SPI, I²C, CAN, and Ethernet;
• interrupt controllers and direct memory access (DMA) engines.

Figure: Simplified computer architecture. Separate arrows show logical communication in both directions; actual buses contain signals whose electrical directions depend on the interface design.

1.4 Input, processing, output, and feedback

A basic computational model is input–process–output. In engineering control systems, output may affect the physical process and thereby change later input. This produces a feedback loop:

Here, k is a discrete sampling index, r[k] is a reference, y[k] is a measured output, x[k] represents stored controller state, u[k] is the computed command, and f is the control algorithm. This expression describes a general discrete computational relationship, not a specific control law. Its variables must be assigned consistent physical units in a real design.

2. From Hardware to Application Software

Software is commonly explained as a hierarchy, but actual systems may combine or omit layers. A desktop operating system differs substantially from a small microcontroller application that runs directly on hardware.

The term firmware describes software stored persistently and associated closely with hardware; it should not automatically be represented as a single layer below drivers. For example, a smart meter's firmware image might contain a bootloader, RTOS, communication drivers, metering algorithms, and an application.

2.1 Compilation, interpretation, and execution

A high-level source program must be translated or otherwise executed:

• A compiler translates source code into machine code or an intermediate representation before execution.
• An interpreter executes source or intermediate instructions through another program.
• A virtual machine executes an abstract instruction set.
• A linker combines compiled modules and libraries, resolves symbols, and creates an executable image.
• A loader places the executable into memory and prepares it to run.

These categories can overlap. Just-in-time systems compile portions of a program during execution, while many embedded toolchains compile and statically link a complete image in advance.

2.2 Timing and resource constraints

For a simple processor model with an average cycles-per-instruction value, estimated CPU execution time is:

where T_CPU is execution time in seconds, N_inst is the number of executed instructions, CPI is average clock cycles per instruction, and f_clk is clock frequency in cycles per second (hertz). The estimate assumes these quantities adequately summarize execution. Caches, interrupts, pipelines, DMA contention, and variable instruction timing may make measurement or worst-case execution-time analysis necessary.

Worked example—execution-time estimate. Suppose a routine executes 12,000 instructions, averages 1.5 cycles per instruction, and runs at 60 MHz:

If the routine must finish every 1 ms, its estimated processor utilization is:

Here, U is the fraction of one processor's available interval used by the routine. A 30% average does not by itself prove deadline compliance: worst-case execution, preemption, blocking, and other tasks must also be considered.

3. Programming Languages and Paradigms

A programming language provides notation and rules for expressing data and computation. Language choice depends on safety, performance, hardware access, available libraries, verification needs, team competence, and product lifecycle—not merely syntax.

3.1 Levels of representation

Machine language contains binary-encoded processor instructions. Assembly language provides symbolic names for instructions, registers, and addresses. High-level languages provide abstractions such as functions, types, modules, objects, and collections.

C and C++ are widely used in embedded systems because they allow efficient code and direct hardware interaction. Python is valuable for simulation, data analysis, test automation, instrumentation, and rapid prototyping. MATLAB and similar technical environments support numerical engineering workflows. Rust is gaining attention for memory-safety guarantees, although tool qualification, ecosystem maturity, and target support remain application-dependent.

3.2 Major paradigms

Paradigms are not mutually exclusive. A C++ embedded application may use objects for hardware interfaces, procedural numerical routines, event-driven interrupts, and concurrent RTOS tasks.

Hardware description languages such as VHDL and Verilog describe digital structures and behavior for synthesis or simulation. Although they use programming-like notation, synthesized logic operates concurrently and should not be interpreted simply as sequential software running on a CPU.

4. Computational Thinking

Computational thinking converts an engineering need into a precise, implementable solution. Four closely related practices are especially important.

4.1 Decomposition

Decomposition divides a complex system into manageable parts with clear responsibilities and interfaces. A battery-monitoring system might be divided into acquisition, calibration, filtering, state estimation, fault detection, communication, and data logging.

Effective decomposition aims for high cohesion within modules and low coupling between them. Modules should perform focused tasks, while dependencies should be explicit. Poor decomposition can distribute safety logic across many components, making testing and change control difficult.

4.2 Pattern recognition and generalization

Engineers recognize recurring structures such as sampling loops, threshold tests, state machines, filtering pipelines, request–response protocols, and producer–consumer queues. A well-understood pattern can reduce design effort, but it must be checked against the new problem's assumptions. A threshold algorithm suitable for a slowly changing temperature may be unsafe for noisy current measurements unless filtering, hysteresis, and timing are considered.

4.3 Abstraction

Abstraction suppresses unnecessary detail while preserving properties relevant to a purpose. A function read_voltage(channel) may hide ADC registers, conversion timing, and calibration coefficients. This allows application code to reason in volts rather than register bit patterns.

Abstraction is purpose-dependent. Hiding ADC timing is convenient for supervisory monitoring but potentially dangerous when precise sample synchronization is required. Engineers must know both how to use an abstraction and when its hidden assumptions matter.

4.4 Representation

A problem can be represented through equations, data structures, state machines, graphs, truth tables, pseudocode, or flowcharts. The chosen representation should expose important constraints. State machines are often effective for operating modes; arrays suit sampled records; graphs suit electrical networks and routing problems.

5. Algorithms: Correctness, Efficiency, and Robustness

An algorithm is a finite, unambiguous sequence of effective steps that transforms defined inputs into outputs. A useful algorithm specification identifies:

• valid inputs and preconditions;
• expected outputs and postconditions;
• processing steps;
• termination conditions;
• error and boundary behavior;
• resource and timing requirements.

5.1 Correctness

An algorithm is correct when it satisfies its specification for every valid input under the stated assumptions. Testing can reveal failures but usually cannot prove correctness over an unlimited input domain. Reasoning techniques include invariants, precondition–postcondition analysis, boundary analysis, and formal verification.

Consider finding the maximum of a nonempty array. The loop invariant can state: after processing elements 0 through i, the variable maximum equals the greatest value among those processed elements. Initialization, preservation, and termination of this invariant establish correctness under the precondition that the array is nonempty and its elements are comparable.

5.2 Time and space complexity

Complexity describes growth in resource use as input size n increases. Common time-complexity classes include constant O(1), logarithmic O(log n), linear O(n), and quadratic O(n²). Big-O notation provides an asymptotic upper-growth classification; it does not directly specify elapsed time or discard the importance of constants for small embedded workloads.

Space complexity matters when RAM is limited. An algorithm that stores every sample may be unsuitable for continuous monitoring, whereas a streaming average may require only a fixed amount of state.

5.3 Numerical and physical robustness

Engineering software operates with finite representations. Integer overflow, quantization, round-off, invalid sensor values, and unit conversion errors can invalidate mathematically sound algorithms. Floating-point equality comparisons require care, but there is no universal tolerance: an appropriate tolerance depends on scaling, uncertainty, numerical method, and application requirements.

Sensor thresholds also require physical reasoning. If a noisy quantity fluctuates around one threshold, output may switch rapidly. Hysteresis uses different activation and deactivation thresholds. If an alarm turns on when I ≥ I_high and turns off when I ≤ I_low, then a valid hysteresis band requires I_low < I_high. Values between the thresholds preserve the current alarm state.

6. Pseudocode and Flowcharts

6.1 Structured pseudocode

Pseudocode expresses algorithmic logic independently of a specific language. It should use consistent indentation, meaningful identifiers, explicit conditions, and defined units.

The following algorithm detects sustained overcurrent using hysteresis. It assumes one current sample arrives every T_s seconds, thresholds use amperes, and confirmSamples is a positive integer.

ALGORITHM UpdateOvercurrentAlarm(currentA)
INPUT: currentA in amperes
STATE: alarmActive ← FALSE
       consecutiveHigh ← 0
CONSTANTS: highThresholdA
           lowThresholdA
           confirmSamples
PRECONDITIONS:
    lowThresholdA < highThresholdA
    confirmSamples ≥ 1

IF currentA is invalid THEN
    report sensor fault
    RETURN alarmActive
END IF

IF alarmActive = FALSE THEN
    IF currentA ≥ highThresholdA THEN
        consecutiveHigh ← consecutiveHigh + 1
        IF consecutiveHigh ≥ confirmSamples THEN
            alarmActive ← TRUE
            consecutiveHigh ← 0
        END IF
    ELSE
        consecutiveHigh ← 0
    END IF
ELSE
    IF currentA ≤ lowThresholdA THEN
        alarmActive ← FALSE
    END IF
END IF

RETURN alarmActive

If sampling is exactly periodic, the nominal confirmation duration is approximately:

where T_confirm is the interval represented by the required samples, N_confirm is confirmSamples, and T_s is the sampling period. The exact elapsed time from the physical onset of overcurrent to declaration can differ by up to roughly one sampling period because onset may occur between samples; scheduling jitter and filtering add further delay.

6.2 Flowcharts

A flowchart depicts control flow graphically. Standard conventions include rounded shapes for start or end, rectangles for processing, diamonds for decisions, and arrows for control flow. Flowcharts are useful for communicating branching logic, but large or concurrent systems are often better represented using state diagrams, sequence diagrams, or structured models.

Figure: Flowchart separating invalid-sensor handling from normal alarm-state processing.

7. Programming in Electrical Engineering

Programming connects mathematical models to physical systems. Representative applications include:

• measurement and instrumentation: acquisition, calibration, filtering, visualization, and uncertainty handling;
• control: digital controllers, estimators, PWM generation, and actuator coordination;
• power systems: load-flow analysis, fault studies, relay logic, and grid monitoring;
• electronics: circuit simulation, automated test, component characterization, and production diagnostics;
• communications: modulation, coding, synchronization, protocol implementation, and software-defined radio;
• signal processing: spectral analysis, filtering, feature extraction, and sensor fusion;
• design automation: optimization, PCB workflows, FPGA development, and verification.

Correct software behavior depends on the complete signal chain. For example, an ADC count must be converted using the converter reference, resolution, analog conditioning, and calibration. A numerically correct conversion formula still gives the wrong physical result if the assumed gain or units do not match the hardware.

7.1 Real-time systems

A real-time system is defined not merely by speed but by the requirement that results be produced within timing constraints. In a hard real-time system, missing a deadline can cause unacceptable failure. In a soft real-time system, occasional deadline misses degrade service but are not necessarily catastrophic.

Interrupt service routines should generally be bounded and short. Shared data require appropriate synchronization, and blocking behavior must be understood. Average execution time is insufficient for safety-critical deadline analysis; worst-case paths and interference must be assessed.

7.2 Testing and verification

Engineering software can be tested at multiple levels:

1. Unit testing checks individual functions or modules.
2. Integration testing checks interactions between components.
3. Hardware-in-the-loop testing connects software or a controller to a simulated physical plant.
4. System testing evaluates the complete product against requirements.
5. Regression testing checks that changes have not broken established behavior.

Boundary values, sensor failures, communication loss, startup, reset, overflow, timing overload, and out-of-range commands deserve explicit tests. Traceability links requirements to design elements, code, tests, and evidence.

8. Illustrative Case: Feeder Overcurrent Monitoring Unit

Background

This fictional case concerns a university–industry prototype for monitoring a low-voltage feeder. A microcontroller samples an isolated current sensor and reports a warning if excessive current persists. The prototype is educational and is not presented as a certified protection relay.

Problem

A single instantaneous threshold produced repeated alarm transitions because of measurement noise and motor-starting transients. The software also performed communication formatting inside the sampling interrupt, causing occasional timing overruns.

The requirements were revised as follows:

• sample current every 0.5 ms;
• activate a warning after 20 consecutive valid samples at or above 15 A;
• clear the warning at or below 13 A;
• detect invalid ADC data;
• keep the sampling interrupt below 100 μs;
• transmit status outside the time-critical interrupt.

Analysis

With T_s = 0.5 ms and N_confirm = 20, the sample-count interval is:

This value is not a universal protection trip time. It is the nominal interval represented by 20 sample periods, before accounting for phase relative to sampling, filter delay, scheduling jitter, sensor response, or actuator time.

The 15 A activation threshold and 13 A clearing threshold provide a 2 A hysteresis band. Values strictly between 13 A and 15 A preserve the current alarm state. Consecutive-sample confirmation rejects short excursions but also delays detection, so its acceptability must be justified from equipment and safety requirements.

Approach and solution

The team decomposed the software into:

• an ADC driver and calibration module;
• a periodic acquisition interrupt;
• a validation and overcurrent state machine;
• a fault manager;
• a communication task;
• a test interface.

The interrupt acquired a sample, recorded a timestamp, and placed the result in a fixed-size queue. The state machine processed samples outside the interrupt but at a scheduling priority sufficient to preserve deadlines. Communication formatting ran at lower priority. Invalid readings generated a distinct sensor fault rather than being treated as zero current.

Tests covered 12.9 A, 13 A, values inside the hysteresis band, 15 A, noisy transitions, 19 consecutive high samples, 20 consecutive high samples, invalid conversion codes, queue overflow, and communication loss. Measured worst-case interrupt execution was 42 μs on the selected hardware, below the 100 μs requirement, although product certification would require stronger evidence and environmental testing.

Outcome

The revised prototype eliminated alarm chatter in the tested noise conditions and prevented communications processing from extending the sampling interrupt. The modular structure also allowed the threshold logic to be tested without physical hardware.

Learning points

1. Decomposition improves timing control and testability.
2. Hysteresis and confirmation serve different purposes: hysteresis limits state chatter, while confirmation rejects short-duration events.
3. Invalid data require explicit handling.
4. Average behavior is not sufficient; boundary cases and worst-case timing matter.
5. Prototype success does not establish regulatory compliance or field safety.

9. Safety, Security, Ethics, and Governance

Software can energize equipment, disable protection, expose operational data, or make decisions affecting people. Professional responsibility therefore extends beyond functional output.

Safety requires hazard analysis, safe states, defensive handling of faults, and appropriate independence between protection mechanisms. Standards depend on domain; examples include IEC 61508 for functional safety, IEC 62304 for medical-device software, and relevant sector-specific derivatives. Their applicability must be determined rather than assumed.

Cybersecurity requires authenticated updates, protected credentials, least privilege, secure communication where justified, dependency management, logging, and vulnerability response. Firmware update mechanisms must consider power loss, rollback, integrity verification, and recovery.

Ethical practice includes honest reporting of limitations, respect for privacy, avoidance of fabricated test evidence, and clear communication of uncertainty. Engineers should not conceal known defects merely to meet delivery dates.

Governance includes version control, code review, requirements traceability, change approval, reproducible builds, configuration management, and retention of verification evidence. These practices make software evolution auditable.

10. Contemporary Developments and Best Practices

Edge computing places analytics and control near sensors, reducing communication latency and bandwidth. Multicore microcontrollers, heterogeneous processors, FPGA acceleration, and model-based design expand implementation choices. Digital twins connect computational models with operational data, while machine learning supports anomaly detection and predictive maintenance.

AI-assisted programming can generate code, tests, and explanations, but generated artifacts may contain unsafe assumptions, nonexistent interfaces, security weaknesses, or licensing concerns. Engineers remain responsible for reviewing requirements, verifying code, testing boundary conditions, and protecting confidential design information.

Sound introductory practice includes:

• define requirements and units before coding;
• separate hardware access from application logic;
• use meaningful types and names;
• keep interfaces explicit and modules cohesive;
• validate inputs and handle failures deliberately;
• avoid unexplained constants;
• measure timing on target hardware;
• test boundaries and fault conditions;
• use version control and peer review;
• document assumptions, limitations, and evidence.

Chapter Summary

Computational engineering rests on an understanding of both hardware and software. Processors execute instructions while exchanging information with memory and peripherals through interconnects. Software concepts are often presented as layers, but embedded firmware may itself contain drivers, an RTOS, middleware, and applications.

Programming languages provide different abstractions and support procedural, object-oriented, functional, event-driven, concurrent, and declarative styles. Computational thinking uses decomposition, pattern recognition, abstraction, and appropriate representation to transform engineering problems into implementable solutions. Algorithms must be judged by correctness, efficiency, timing, numerical behavior, robustness, and resource use.

Pseudocode and flowcharts communicate logic before language-specific implementation. In electrical engineering, programming enables measurement, control, protection, communications, simulation, and automation. Because software acts on physical systems, engineers must address real-time constraints, testing, safety, cybersecurity, ethics, configuration control, and regulatory obligations throughout the lifecycle.

Key Terms

Algorithm: A finite and unambiguous procedure that transforms specified inputs into outputs.

Abstraction: A representation that hides selected implementation details while preserving relevant behavior.

Central processing unit (CPU): The component that executes machine instructions and controls computational operations.

Computational thinking: Systematic formulation of problems and solutions in forms suitable for computation.

Decomposition: Division of a complex problem or system into manageable components.

Device driver: Software that controls or provides access to a hardware device.

Firmware: Persistent software closely associated with a device, potentially including drivers, operating services, and applications.

Flowchart: A graphical representation of control flow using standardized shapes and arrows.

Hysteresis: State-dependent threshold behavior using different activation and deactivation limits.

Instruction-set architecture: The programmer-visible machine instructions, registers, data types, and execution model of a processor.

Interconnect: Hardware pathways and protocols that transfer information among computer components.

Interrupt: An event that causes a processor to suspend normal execution and invoke a handler.

Pseudocode: Language-independent structured notation for describing algorithms.

Real-time system: A system whose correctness depends on both logical results and their timing.

Register: Small, fast storage located within or closely coupled to a processor.

Software paradigm: A general style for structuring data and computation.

State machine: A model whose behavior is represented by states and transitions triggered by conditions or events.

Time complexity: The asymptotic growth of an algorithm's operation count with input size.

Traceability: Documented linkage among requirements, design, implementation, tests, and evidence.

Worst-case execution time: An upper bound or justified estimate of the longest execution time under stated conditions.

Review Questions

Short Answer Questions

1. What functions are performed by the ALU, control unit, and processor registers?
2. Why does normal processor–memory communication require logical information flow in both directions?
3. Why should firmware not always be represented as a strict layer below device drivers?
4. Distinguish abstraction from decomposition.
5. What is the purpose of hysteresis in a threshold-based alarm?

Long Answer Questions

1. Explain the computer memory hierarchy and discuss how latency, capacity, persistence, and cost influence its organization.
2. Compare procedural, object-oriented, functional, event-driven, and concurrent paradigms in the context of electrical engineering applications.
3. Discuss the properties of a well-specified algorithm, including preconditions, postconditions, termination, correctness, and resource use.
4. Explain the software development and testing practices required for a real-time embedded engineering system.
5. Discuss safety, cybersecurity, ethics, and governance responsibilities in software-controlled electrical equipment.

Analytical / Application Questions

1. A control routine executes 25,000 instructions at an average of 2 cycles per instruction on a 100 MHz processor. Estimate its CPU execution time under the simplified model and determine its utilization if it runs every 2 ms. Explain why the calculation does not prove deadline compliance.
2. Design pseudocode for a temperature alarm that activates after five consecutive valid readings at or above 90 °C, clears at or below 85 °C, and reports invalid sensor readings separately.
3. Decompose a solar-inverter monitoring application into modules. Identify the interfaces, units, timing constraints, likely failure modes, and tests for each major module.

Multiple Choice Questions with Answers

Question 1

Which processor component primarily performs arithmetic and Boolean operations?

A. Arithmetic and logic unit

B. Program loader

C. Secondary storage

D. Device driver

Correct Answer: A. Arithmetic and logic unit

Question 2

Why does the architecture figure show communication in both directions between the processor and memory?

A. Memory independently compiles source code

B. The processor sends requests or writes, while memory returns instructions or data

C. Every individual bus wire always carries signals in both directions

D. Memory directly controls all external actuators

Correct Answer: B. The processor sends requests or writes, while memory returns instructions or data

Question 3

Which statement most accurately describes firmware?

A. It is always a strict layer beneath every device driver

B. It refers only to a processor's instruction set

C. It is persistent device-associated software that may include drivers, an RTOS, and applications

D. It must execute without any operating system services

Correct Answer: C. It is persistent device-associated software that may include drivers, an RTOS, and applications

Question 4

A routine executes 12,000 instructions at 1.5 cycles per instruction on a 60 MHz processor. Under the simplified execution-time model, how long does it take?

A. 30 μs

B. 200 μs

C. 300 μs

D. 3 ms

Correct Answer: C. 300 μs

Question 5

Which computational-thinking practice divides a monitoring system into acquisition, filtering, fault detection, and communication modules?

A. Interpretation

B. Decomposition

C. Quantization

D. Compilation

Correct Answer: B. Decomposition

Question 6

An alarm turns on at currents of at least 15 A and turns off at currents of at most 13 A. What occurs at 14 A?

A. The alarm must turn on

B. The alarm must turn off

C. The alarm preserves its current state

D. The sensor reading is necessarily invalid

Correct Answer: C. The alarm preserves its current state

Question 7

Which property distinguishes a real-time system from a system that is merely fast?

A. It uses a high clock frequency

B. It contains no operating system

C. Its correctness includes meeting specified timing constraints

D. It is programmed only in assembly language

Correct Answer: C. Its correctness includes meeting specified timing constraints

Question 8

Twenty consecutive samples are required for confirmation, and samples occur every 0.5 ms. What nominal interval is represented by the sample count?

A. 4 ms

B. 10 ms

C. 20 ms

D. 40 ms

Correct Answer: B. 10 ms

Question 9

Which test arrangement connects a controller to a simulated physical plant to evaluate behavior?

A. Static linking

B. Unit compilation

C. Hardware-in-the-loop testing

D. Source formatting

Correct Answer: C. Hardware-in-the-loop testing

Question 10

Which practice is most appropriate when using AI-generated code in an embedded electrical system?

A. Deploy it directly if it compiles

B. Treat it as verified because it was generated automatically

C. Review requirements, inspect the code, and test timing and boundary behavior

D. Omit version control to avoid storing generated content

Correct Answer: C. Review requirements, inspect the code, and test timing and boundary behavior