Concept Generation and System Architecture

Introduction

A major engineering project rarely begins with a fully defined circuit, controller, communication protocol, or power-conversion topology. It begins with a need, constraint, or opportunity. The engineer must transform that need into alternative technical concepts, compare those concepts systematically, and develop an architecture that can be designed, implemented, tested, and defended.

Concept generation and system architecture connect problem definition with detailed engineering design. Concept generation asks, “What different solutions could satisfy the requirements?” System architecture asks, “How will the selected solution be divided into interacting subsystems, and how will those subsystems exchange energy, information, and control?”

These activities are especially important in electrical engineering because the same function may be achieved through different combinations of power electronics, sensors, embedded processors, communication networks, control algorithms, and software. A poor early decision can create excessive cost, unsafe operation, difficult testing, or an architecture that cannot be modified when requirements change.

This chapter develops a disciplined process for generating alternatives and transforming a selected concept into functional block diagrams, technical specifications, interfaces, and hardware–software architectures.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Translate stakeholder needs into measurable engineering requirements.
2. Generate multiple feasible concepts rather than selecting the first plausible solution.
3. Compare alternatives using weighted decision methods and engineering judgement.
4. Develop functional, physical, information-flow, and hardware–software architectures.
5. Define subsystem boundaries, interfaces, data flows, timing, power, and safety requirements.
6. Apply preliminary calculations to size and screen candidate solutions.
7. Recognize trade-offs, uncertainty, ethical responsibilities, and verification needs.
8. Document architectural decisions in a form suitable for a dissertation or major-project review.

1. From Need to Engineering Requirements

A stakeholder statement is usually qualitative. For example, “Develop an affordable system that monitors room temperature and reduces energy consumption” does not directly specify sensors, sampling rates, control accuracy, communication methods, or safety limits. Requirements engineering converts such a statement into verifiable conditions.

A useful requirement should be:

• Necessary: it supports a real stakeholder or system need.
• Unambiguous: it has one reasonable interpretation.
• Measurable: compliance can be tested or inspected.
• Traceable: its origin and associated verification method are known.
• Feasible: it can be met within time, cost, energy, and technology limits.
• Prioritized: essential requirements are distinguished from desirable ones.

Requirements may be classified as follows:

A requirement should also specify operating conditions. A sensor accuracy requirement, for example, is incomplete unless the temperature range, humidity, supply voltage, calibration status, and time interval are stated.

1.1 Requirements traceability

Traceability links needs to requirements, functions, design elements, and verification tests. A simple traceability chain is:

Need → System requirement → Subsystem requirement → Design element → Verification evidence

For example:

Traceability reduces the risk of designing impressive features that do not address the original problem. It also helps identify requirements with no implementation or tests with no requirement.

2. Functional Decomposition

Before selecting components, the overall purpose should be decomposed into functions. A function describes what the system must do, not how it will do it. “Acquire temperature” is a function; “use an LM35 sensor” is a design choice.

A typical decomposition for an embedded monitoring and control system is:

1. Supply and regulate energy.
2. Sense physical variables.
3. Condition and convert sensor signals.
4. Process measurements.
5. Estimate system state.
6. Compare state with desired operating conditions.
7. Drive actuators.
8. Communicate status and faults.
9. Store configuration and event data.
10. Protect people, equipment, and data.

Functional decomposition supports alternative concepts. The sensing function may be achieved with an analogue sensor and ADC, a digital sensor using I²C, or a remote sensor connected through a field bus. These are alternatives at the functional level before they become component selections.

2.1 Functional versus physical architecture

A functional architecture represents transformations and flows: energy enters, a measurement is produced, an algorithm calculates a control action, and an actuator changes the plant.

A physical architecture assigns functions to real elements: power supply, microcontroller, sensor board, MOSFET driver, motor, display, and communication module.

The two views should not be confused. One physical component may perform several functions, and one function may be distributed across hardware and software. Maintaining both views makes design reasoning clearer.

Figure: A generic closed-loop embedded system architecture. The feedback path is physical; the status path communicates information to the controller or user interface.

3. Concept Generation Methods

Concept generation should be broad before it becomes selective. A project team should deliberately produce several credible alternatives, including at least one that differs fundamentally from the leading idea.

3.1 Function–means analysis

For each function, list possible means of implementation. A matrix can reveal combinations that are not immediately obvious.

The alternatives must be technically compatible. A current transformer is not generally suitable for measuring steady dc, whereas a shunt resistor can measure dc but introduces power loss and requires careful isolation design.

3.2 Morphological analysis

A morphological chart systematically combines alternatives from several functions. The resulting combinations are then screened for compatibility, safety, cost, and performance. Not every combination is feasible; the chart is a creativity and completeness tool, not an automatic design generator.

3.3 Analogy and reuse

Existing products, reference designs, industrial standards, and known circuit topologies can stimulate concepts. Reuse reduces technical risk, but copying without understanding may introduce hidden licensing, thermal, electromagnetic-compatibility, or safety problems.

3.4 First-principles feasibility checks

A concept should be rejected early if a simple physical estimate shows that it cannot work. For a resistive load, electrical power is:

Here, P is power in watts, V is voltage in volts, I is current in amperes, and R is resistance in ohms. These equivalent forms apply to a linear resistive element under dc or instantaneous conditions. For ac circuits, impedance and rms quantities must be used appropriately.

For a 24 V, 6 Ω resistive load, the required current is:

and the power is:

A proposed 1 A power supply is therefore infeasible, even before losses and transient current are considered.

For a capacitor used as a smoothing element, the approximate voltage change under a constant load current is:

where ∆V is voltage change in volts, I is load current in amperes, ∆t is discharge time in seconds, and C is capacitance in farads. The approximation assumes constant current and neglects capacitor equivalent series resistance and leakage. If a 0.5 A load is supplied for 2 ms by a 2,000 µF capacitor, then ∆V ≈ (0.5 × 0.002)/0.002 = 0.5 V.

These estimates do not complete the design, but they efficiently eliminate impossible alternatives.

4. Selecting Among Alternatives

Selection should be explicit rather than based on enthusiasm or familiarity. Common criteria include performance, safety, cost, efficiency, size, maintainability, availability, scalability, development time, environmental robustness, and regulatory compliance.

A weighted decision matrix is useful when criteria have different importance. If alternative j has normalized score s_ij against criterion i, and criterion weight w_i, the total score is:

The weights should satisfy ∑w_i = 1, and scores must use the same defined scale, such as 1 to 5. A high score does not prove that an alternative is safe or technically valid; mandatory constraints must be screened first.

Worked selection example

Suppose three communication options are evaluated using cost, range, reliability, and development effort. The weights are 0.20, 0.25, 0.35, and 0.20 respectively. Scores from 1 to 5 are:

The CAN score is:

The UART and Wi-Fi scores are 3.75 and 3.20 respectively. CAN is preferred by this matrix, but the decision should be revisited if the project has a strict range requirement or if electromagnetic conditions make a particular physical layer unsuitable.

Avoiding misuse of decision matrices

A matrix can create false precision. A score of 4 is not necessarily twice as good as a score of 2, and changing weights may change the result. Good practice includes documenting score definitions, identifying non-negotiable constraints, conducting sensitivity analysis, and recording the reasons behind the final decision.

5. System Architecture

System architecture defines the major elements, their responsibilities, and their relationships. A useful architecture answers five questions:

1. What functions must be performed?
2. Which elements perform those functions?
3. What energy, information, and material flows connect the elements?
4. What interfaces and protocols govern those flows?
5. How are faults detected, contained, and recovered?

5.1 Architecture viewpoints

A robust project normally uses several complementary diagrams:

• Context diagram: system boundary and external actors or systems.
• Functional block diagram: transformations and functional flows.
• Physical block diagram: actual hardware and software elements.
• Data-flow diagram: data sources, processing, storage, and destinations.
• Power-flow diagram: sources, converters, protection, and loads.
• State diagram: operating modes and transitions.
• Deployment diagram: physical location of processors, sensors, and networks.

No single diagram can communicate all design information. Every diagram should have a stated purpose, legend, version, and boundary.

5.2 Boundaries and cohesion

A subsystem boundary should group functions that are closely related and minimize unnecessary coupling. For example, a motor-driver module may contain gate drive, current measurement, local protection, and a power switch. Separating the gate driver from the power switch may be appropriate for modular testing, but it can increase interface complexity.

A good architecture promotes:

• High cohesion: elements within a subsystem support a related purpose.
• Low coupling: subsystems depend on as few assumptions as possible.
• Information hiding: internal implementation details are not exposed unnecessarily.
• Replaceability: one sensor or communication module can be changed without redesigning the whole system.
• Testability: interfaces permit observation, stimulation, and isolation.

6. Interface Definition

An interface is more than a wire. It is a contract describing what crosses a subsystem boundary and under what conditions.

An interface specification should define:

For a digital measurement, the specification might state: “The sensor transmits signed temperature values in 0.01 °C units over I²C at 400 kbit/s; a read transaction shall complete within 5 ms; invalid data shall be rejected by a range and checksum check.”

6.1 Electrical compatibility

Logic voltage compatibility must be checked rather than assumed. A 5 V output connected directly to a 3.3 V input may exceed the input’s absolute maximum rating. Open-drain buses require suitable pull-up resistors, and line capacitance limits the achievable rise time. Analogue interfaces require attention to source impedance, ADC reference voltage, common-mode range, grounding, and filtering.

For a resistive divider:

where R₁ is the upper resistor, R₂ is the lower resistor, and the load is assumed sufficiently high that it does not significantly alter the ratio. If V_in = 12 V, R₁ = 30 kΩ, and R₂ = 10 kΩ, then V_out = 3 V. The resistor power ratings and input protection must still be checked.

7. Hardware–Software Architecture

Embedded systems distribute functions between physical electronics and software. The boundary should be chosen according to timing, safety, cost, flexibility, power, verification, and maintainability.

7.1 Hardware responsibilities

Hardware is usually preferred for functions requiring deterministic timing, high-speed switching, signal conditioning, isolation, fault containment, or operation when the processor is unavailable. Examples include overcurrent comparators, gate-driver interlocks, fuses, watchdog reset circuits, and emergency shutdown paths.

7.2 Software responsibilities

Software is useful for complex algorithms, communication management, calibration, logging, user configuration, diagnostics, and functions likely to change during development. Software should not be the only protection against hazards when an independent hardware safeguard is reasonably practicable.

7.3 Layered architecture

A maintainable embedded architecture often contains:

1. Hardware abstraction layer: microcontroller registers and device drivers.
2. Board support and peripheral services: ADC, timers, communication, storage.
3. Application services: filtering, estimation, diagnostics, data logging.
4. Control and decision layer: state machine and control law.
5. Interface layer: display, host communication, and configuration.

A state machine makes operating modes explicit. Typical states are Initialise, Self-test, Idle, Run, Fault, and Safe shutdown. Transitions should be triggered by defined events, not by uncontrolled combinations of flags.

7.4 Sampling and timing

For a sampled control system, the sampling frequency must be related to the dynamics of the plant and the controller. The Nyquist condition for avoiding aliasing of a band-limited signal is:

where f_s is sampling frequency and f_max is the highest frequency component of interest. This is a theoretical minimum, not a universal design recommendation. Practical control systems often sample substantially faster, and an analogue anti-aliasing filter is required before the ADC.

If a task must execute every 10 ms, its worst-case execution time, including interrupt interference and communication delays, must be less than the available deadline. Average execution time is insufficient for real-time assurance.

8. Preliminary System Specifications

Specifications should express measurable targets and tolerances. Important categories include:

• Electrical ratings: voltage, current, power, insulation, grounding.
• Dynamic performance: response time, bandwidth, overshoot, settling time.
• Measurement performance: range, resolution, accuracy, repeatability, drift.
• Computing performance: clock rate, memory, execution time, communication load.
• Environmental performance: temperature, humidity, vibration, ingress protection.
• Reliability and service: expected life, diagnostic coverage, maintainability.
• Human and economic factors: usability, accessibility, cost, repairability.

Power-budget calculations should include conversion losses. If a load consumes P_L and a converter has efficiency η, the input power is:

For a 40 W load and 80% efficiency, P_in = 40/0.80 = 50 W. The 10 W difference becomes heat or other loss. If the supply voltage is 12 V, the average input current is approximately 50/12 = 4.17 A, excluding startup and transient margins.

Thermal feasibility requires more than electrical power. A simplified component temperature estimate is:

where T_j is junction temperature, T_a is ambient temperature, P_loss is dissipated power, and θ_JA is junction-to-ambient thermal resistance in °C/W. This relationship assumes steady state and a defined thermal environment. Heat sinks, airflow, enclosure effects, and transient thermal impedance may require a more detailed model.

9. Verification-Oriented Architecture

Architecture should make verification possible. Each requirement needs a verification method:

• Inspection: confirm a physical or documentary property.
• Analysis: use calculations, simulation, or modelling.
• Test: measure response under controlled conditions.
• Demonstration: show operation in a representative scenario.

A subsystem should have observable inputs and outputs. Test points, diagnostic messages, calibration access, simulated sensor inputs, and fault injection provisions can greatly reduce project risk. A design that cannot be tested efficiently is not complete, even if its nominal operation appears satisfactory.

A verification matrix may include requirement ID, acceptance criterion, equipment, procedure, expected result, actual result, and evidence location. Requirements involving safety should be tested under fault conditions, not only normal operation.

10. Illustrative Case Study: Solar-Powered Battery Monitoring System

The following is a fictional illustrative case for educational purposes.

Background

A student team must develop a prototype that monitors a 12 V lead-acid battery charged from a small photovoltaic panel. The system shall display voltage and current, estimate charging status, disconnect a noncritical load during low voltage, and transmit logged data to a laptop.

Problem and requirements

The initial stakeholder request is broad. The team converts it into preliminary requirements:

• Measure battery voltage from 10.5 V to 15.0 V.
• Measure load current up to 5 A.
• Update the display at least once per second.
• Disconnect the load below a selected low-voltage threshold.
• Protect the measurement electronics from supply transients.
• Store or transmit time-stamped measurements.
• Ensure that a sensor or software fault cannot leave the load permanently in an unsafe state.

Alternative concepts

Three architectures are generated:

Concept C offers a convenient user interface but has higher power consumption, slower startup, and less deterministic low-level protection. Concept A is inexpensive but requires careful ADC calibration and relay wear considerations. Concept B offers integrated measurement capability, efficient switching, and sufficient processing capacity.

Architecture decision

Concept B is selected after mandatory checks for voltage range, current rating, switching transients, and availability. The architecture contains:

1. Input protection and regulated supply.
2. Voltage and current measurement.
3. Microcontroller with ADC and communication peripherals.
4. Hardware undervoltage comparator as an independent protection path.
5. MOSFET load switch with gate driver and flyback protection if the load is inductive.
6. Firmware state machine, calibration, logging, and communications.
7. Laptop interface for configuration and data export.

Preliminary calculation

The voltage divider must reduce a maximum battery voltage of 15 V to an ADC range of 0–3.3 V. A ratio below 3.3/15 = 0.22 is required. Selecting R₁ = 39 kΩ and R₂ = 10 kΩ gives:

The divider current at 15 V is approximately 15/(49 kΩ) = 0.306 mA, which limits power loss but makes the node more susceptible to noise and input leakage. An analogue capacitor and suitable input impedance are therefore considered, and the final design verifies ADC acquisition time and filtering.

If the shunt resistance is 20 mΩ and the maximum current is 5 A, the nominal measurement voltage is:

The shunt dissipates:

A component with adequate continuous rating and thermal margin is required. The small signal voltage also requires an amplifier or current-monitor IC with appropriate offset and common-mode performance.

Software architecture

The firmware operates in the following states:

• Initialise: configure clocks, ADC, communication, and outputs.
• Self-test: check sensor ranges and memory.
• Monitor: sample voltage and current, filter data, and update the display.
• Load enabled: permit normal operation when limits are satisfied.
• Low-voltage fault: open the MOSFET and record the event.
• Recovery: re-enable only after voltage remains above the recovery threshold for a defined time.

The hardware comparator can disable the gate even if the microcontroller is locked. Firmware periodically checks a watchdog and validates measurements against plausible ranges. Communication commands cannot directly bypass the hardware protection path.

Outcome

The architecture provides independent protection, clear subsystem boundaries, and testable interfaces. The team can test the measurement board separately from the load switch and can inject simulated sensor values during firmware development. The principal remaining risks are battery fault current, reverse polarity, transient spikes from wiring, calibration error, and incorrect assumptions about battery state of charge.

Learning points

The case demonstrates that architecture is not simply a block diagram. It embodies safety decisions, measurement assumptions, timing requirements, interfaces, fault responses, and verification strategy. It also shows why a system-level requirement such as “protect the battery” must be decomposed into electrical, software, mechanical, and testable provisions.

11. Challenges, Ethics, and Contemporary Practice

Uncertainty and changing requirements

Projects often begin with incomplete information. Assumptions should be recorded with confidence levels and validation plans. Interfaces should avoid unnecessary dependence on uncertain details. Prototyping a high-risk interface early is usually more valuable than polishing a low-risk subsystem.

Safety and professional responsibility

Electrical engineers are responsible for foreseeable hazards including electric shock, fire, stored energy, thermal runaway, unexpected motion, and loss of control. Protective barriers, current limiting, fusing, isolation, grounding, emergency stops, watchdogs, and fail-safe states should be selected according to the application. Relevant institutional, national, and product standards must be identified rather than assumed. A university prototype is not automatically exempt from safety obligations.

Claims about performance must be supported by evidence. Fabricated measurements, undocumented calibration, unreported failures, and selective presentation of favourable results are unacceptable research practices. Design files, source code, test data, assumptions, and revisions should be controlled and reproducible.

Cybersecurity and data governance

Connected electrical systems may be exposed to unauthorized commands, corrupted firmware, or manipulated sensor data. Threat modelling should consider authentication, access control, secure updates, input validation, logging, and recovery. If the system collects personal or operational data, storage, retention, consent, and access should comply with applicable institutional and legal requirements.

AI-assisted engineering

AI tools can help generate candidate architectures, summarize standards, inspect code patterns, or propose test cases. They cannot replace engineering accountability. Generated circuit values, code, safety claims, and references require independent verification. Sensitive project data should not be uploaded to tools without authorization, and authorship and tool use should be disclosed according to institutional policy.

Contemporary developments

Modern architectures increasingly use model-based systems engineering, digital twins, edge computing, software-defined instrumentation, modular power stages, and machine-learning-assisted diagnostics. These technologies can improve flexibility but introduce additional dependencies, computational demand, explainability concerns, and cybersecurity risks. The appropriate architecture remains the simplest one that satisfies verified requirements with acceptable risk.

12. Best Practices for a Major Project

1. Define the system boundary before drawing detailed blocks.
2. Separate needs, requirements, functions, and implementation choices.
3. Generate several alternatives and record rejected concepts and reasons.
4. Apply mandatory constraints before weighted scoring.
5. Use at least one functional diagram and one physical architecture diagram.
6. Label every important interface with units, direction, timing, and limits.
7. Allocate safety functions independently where practical.
8. Make assumptions explicit and test the highest-risk assumptions early.
9. Maintain requirement, design, and verification traceability.
10. Design for calibration, fault injection, observation, and maintenance.
11. Include power, thermal, EMC, mechanical, and cybersecurity considerations.
12. Version-control diagrams, specifications, firmware, calculations, and test evidence.
13. Revisit the architecture after prototype results; architecture is an evolving model, not a one-time drawing.

Chapter Summary

Concept generation transforms an engineering need into multiple technically plausible alternatives. Requirements must be measurable, traceable, prioritized, and linked to verification. Functional decomposition describes what the system must do, while physical architecture assigns those functions to hardware, software, and human or external elements.

Morphological analysis and function–means tables help produce alternatives. Weighted decision matrices support transparent comparison, but they must not replace feasibility checks, safety screening, or engineering judgement. Preliminary equations for power, voltage division, capacitor droop, power conversion, and thermal estimation can eliminate infeasible concepts early.

System architecture should communicate boundaries, flows, interfaces, timing, energy, data, operating states, and fault responses. Hardware–software partitioning should consider determinism, safety, flexibility, maintainability, and verification. A strong architecture is testable, traceable, modular, and robust to foreseeable faults. Ethical practice requires honest evidence, protection of people and data, respect for standards, and independent verification of AI-assisted or externally supplied material.

Key Terms

Architecture: The organized structure of system elements, relationships, interfaces, and responsibilities.

Concept generation: The systematic creation of alternative ways to satisfy a need or requirement.

Constraint: A condition that limits an allowable design solution.

Data flow: The movement and transformation of information between system elements.

Functional architecture: A representation of required functions and their logical relationships.

Functional decomposition: Breaking a system purpose into smaller interacting functions.

Interface: A defined boundary and contract through which energy, information, or material passes.

Low coupling: A property in which subsystems have minimal unnecessary dependence on one another.

Morphological chart: A table listing alternative means for each system function.

Physical architecture: The allocation of functions to actual hardware, software, people, or external systems.

Requirement: A necessary and verifiable statement of what a system shall do or possess.

Safety function: A function intended to prevent or limit hazardous operation.

State machine: A model of operating states and the events that cause transitions between them.

System boundary: The defined separation between the system being designed and its environment.

Traceability: The ability to follow a requirement through design elements and verification evidence.

Verification: The process of establishing that a requirement has been satisfied.

Weighted decision matrix: A structured comparison in which criteria receive importance weights and alternatives receive scores.

Worst-case execution time: The maximum time a software task may require under defined conditions.

Review Questions

Short Answer Questions

1. Distinguish between a functional architecture and a physical architecture.
2. List four characteristics of a good engineering requirement.
3. Why should mandatory constraints be checked before using a weighted decision matrix?
4. What information should be included in an interface specification?
5. State two reasons for assigning some safety functions to hardware rather than software.

Long Answer Questions

1. Explain how a stakeholder need can be transformed into requirements, functions, architecture, and verification evidence.
2. Describe a morphological analysis process for developing alternative concepts for an embedded electrical system.
3. Explain the principles of high cohesion, low coupling, information hiding, and testability in system architecture.
4. Discuss the factors that should influence hardware–software partitioning in a real-time control system.
5. Describe how safety, cybersecurity, ethics, and regulatory considerations should influence an electrical engineering project architecture.

Analytical / Application Questions

1. A 24 V actuator draws 3 A continuously and is driven by a converter with 85% efficiency. Calculate the approximate converter input power and explain what additional checks are needed before selecting the power supply.
2. Design a preliminary architecture for a remote water-pump controller. Identify at least three alternative sensing or communication methods, define the major interfaces, and propose two independent responses to a dangerous overpressure condition.
3. A project team selects Wi-Fi because it receives the highest weighted score, but later discovers that the installation has severe electromagnetic interference and requires deterministic fault reporting. Critically evaluate the original decision and recommend an improved selection process.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a functional architecture?

A. It assigns every function to a specific commercial component.

B. It represents the required functions and the flows between them.

C. It lists only the software modules used by the system.

D. It specifies the enclosure dimensions and mounting holes.

Correct Answer: B. It represents the required functions and the flows between them.

Question 2

For a 24 V, 6 Ω resistive load, what is the nominal current?

A. 0.25 A

B. 2 A

C. 4 A

D. 144 A

Correct Answer: C. 4 A

Question 3

In a weighted decision matrix, what condition normally applies to the criterion weights?

A. All weights must be greater than 5.

B. The weights must sum to 1 when expressed as normalized fractions.

C. Each weight must equal the corresponding score.

D. Weights are used only after prototype construction.

Correct Answer: B. The weights must sum to 1 when expressed as normalized fractions.

Question 4

Which item is primarily a timing property of an interface?

A. Connector colour

B. Byte order

C. Latency

D. Enclosure material

Correct Answer: C. Latency

Question 5

A 40 W load is supplied by a converter with 80% efficiency. What is the approximate input power?

A. 32 W

B. 40 W

C. 48 W

D. 50 W

Correct Answer: D. 50 W

Question 6

Why is an analogue anti-aliasing filter used before an ADC?

A. To increase the processor clock frequency

B. To reduce unwanted frequency components that could be aliased during sampling

C. To convert all digital data into analogue voltage

D. To provide mechanical isolation for the sensor

Correct Answer: B. To reduce unwanted frequency components that could be aliased during sampling

Question 7

Which architecture property means that elements within a subsystem support closely related purposes?

A. High cohesion

B. High coupling

C. Low resolution

D. Redundancy loss

Correct Answer: A. High cohesion

Question 8

For a 12 V input, 39 kΩ upper resistor, and 10 kΩ lower resistor, what is the ideal divider output assuming a high-impedance load?

A. 1.20 V

B. 2.45 V

C. 3.00 V

D. 4.90 V

Correct Answer: C. 3.00 V

Question 9

Which verification method primarily uses calculations, simulation, or modelling?

A. Inspection

B. Analysis

C. Demonstration

D. Assembly

Correct Answer: B. Analysis

Question 10

What is the principal danger of treating an AI-generated circuit or safety claim as automatically correct?

A. AI tools always produce analogue circuits only.

B. The claim may be unverified and unsuitable for the actual requirements or hazards.

C. AI-generated material cannot contain numerical values.

D. The result will necessarily use excessive power.

Correct Answer: B. The claim may be unverified and unsuitable for the actual requirements or hazards.