Repository navigation
Chapter Guide
Every chapter with the questions it opens with and its sections. Click a chapter to read it on GitHub.
Every system in this book, from a sensor node to a microgrid, is built by one chain of work: problem to requirements, requirements to architecture, architecture to models and prototypes, prototypes to a verified, documented product that someone else can build again. Part I teaches that chain as a method, before the later parts apply it to instrumentation, embedded devices, robots, factories, energy systems, communications and software. Its rule runs through the whole book: every decision is traced to a number written down before the build, and every number is closed by a test with a pass/fail limit. Two small running systems carry the method. Chapters 1–3 follow CCM-1, a battery-powered remote temperature monitor for vaccine refrigerators, from a one-sentence brief to a validated architecture. Chapters 4–5 follow PM-4, a four-channel 12 V DC power monitor for server racks, through prototypes, tests, calibration, release and a field return.
Part opener: part-1-engineering-design-methodology/README.md
How does a vague need become a set of measurable, verifiable requirements, and where does the system end?
How are requirements turned into design specifications, traced through the design, and closed by acceptance tests with pass/fail limits?
9 sections · 6 figures
- 1.1 Problem definition
- 1.2 Stakeholder requirements
- 1.3 Functional requirements
- 1.4 Nonfunctional requirements
- 1.5 System boundaries
- 1.6 Constraints
- 1.7 Design specifications
- 1.8 Requirements traceability
- 1.9 Acceptance criteria
How is a set of requirements decomposed into functions and allocated to hardware and software blocks with well-defined interfaces?
How are data, energy and control flows budgeted through the architecture, and how are the big choices made and recorded so that they survive the first surprise?
10 sections · 6 figures
- 2.1 Functional decomposition
- 2.2 Block diagrams
- 2.3 Hardware–software partitioning
- 2.4 Interfaces
- 2.5 Data flow
- 2.6 Energy flow
- 2.7 Control flow
- 2.8 Modularity
- 2.9 Trade-off analysis
- 2.10 Architecture documentation
How is a model built to answer a specific design question, at the right level of detail, with a solver that cannot silently mislead?
How are model parameters estimated, their influence measured and the model validated, so that a simulation result can carry a design decision and be reproduced later?
10 sections · 6 figures
- 3.1 Mathematical modeling
- 3.2 Equivalent circuits
- 3.3 System-level simulation
- 3.4 Component-level simulation
- 3.5 Numerical solver selection
- 3.6 Model assumptions
- 3.7 Parameter estimation
- 3.8 Sensitivity analysis
- 3.9 Model validation
- 3.10 Simulation reproducibility
What must each prototype prove, and how do you choose the instruments, tests and limits that prove it?
When a prototype fails, how do you find the cause quickly, fix it, and make sure the same fault never comes back unnoticed?
10 sections · 5 figures
- 4.1 Prototype planning
- 4.2 Breadboarding
- 4.3 PCB prototyping
- 4.4 Instrument selection
- 4.5 Test plans
- 4.6 Verification versus validation
- 4.7 Calibration
- 4.8 Fault diagnosis
- 4.9 Regression testing
- 4.10 Design iteration
Which documents does a working system need, and what must each contain so that someone else can build, test and change it?
How are those documents kept consistent with each other and with the hardware and firmware actually shipped, revision after revision?
10 sections · 5 figures
- 5.1 Schematics
- 5.2 Block diagrams
- 5.3 Wiring diagrams
- 5.4 Bill of materials
- 5.5 Design calculations
- 5.6 Test reports
- 5.7 Version control
- 5.8 Technical documentation
- 5.9 Revision management
- 5.10 Reproducibility
Every system in this book is judged by measurements: an efficiency map, a battery's capacity, a robot's position error, a power-quality report, a verification table with a pass or a fail in its last column. Part II is about making those numbers trustworthy. It follows a measurement from the physical quantity to a stored, timestamped, validated record — sensor, conditioning, conversion, acquisition, storage — and treats each link the way Part I taught: as a requirement with a target, a budget with a margin, a part chosen against alternatives, a test with a limit and a failure analysed until its mechanism is known. Four running systems carry the method: a 15 kW motor test bench (sensors), an isolated strain-gauge module for a fatigue rig (conditioning), a three-node acquisition system for a 150 kW drive dynamometer (acquisition), and the instrument suite of the laboratory that houses them (complete instruments).
Part opener: part-2-instrumentation-and-measurement-systems/README.md
How do you choose a sensor so that the measurement, not the catalogue, meets the requirement, including range, accuracy, dynamics, environment and interface?
What does each sensor family really deliver on a bench, where does it fail, and how is it calibrated traceably?
11 sections · 5 figures
- 6.1 The test bench and its measurement requirements
- 6.2 Temperature sensors
- 6.3 Pressure sensors
- 6.4 Position sensors
- 6.5 Speed sensors
- 6.6 Force and strain sensors
- 6.7 Light sensors
- 6.8 Magnetic sensors
- 6.9 Current and voltage sensors
- 6.10 Sensor selection
- 6.11 Sensor calibration
How is a chain from a millivolt-level sensor to a digital number designed so that its range, resolution and uncertainty are known before it is built?
Which conditioning decisions — bridge, amplifier, filters, isolation, converter, sampling — decide whether a measurement survives a real installation rather than a bench?
11 sections · 6 figures
- 7.1 Measurement range and resolution
- 7.2 Accuracy and precision
- 7.3 Error and uncertainty
- 7.4 Bridge circuits
- 7.5 Instrumentation amplifiers
- 7.6 Filtering
- 7.7 Isolation
- 7.8 ADC and DAC selection
- 7.9 Sampling
- 7.10 Noise reduction
- 7.11 Implementation, verification and failure analysis
How is a multi-node acquisition system architected so that thousands of channels at very different rates arrive complete, aligned in time and traceable to their calibration?
How are real-time transfer, logging, storage and validation designed so that a lost sample, a clock fault or a bad sensor is detected rather than analysed?
11 sections · 6 figures
- 8.1 DAQ architectures
- 8.2 Sensor interfaces
- 8.3 ADC performance
- 8.4 Sampling rates
- 8.5 Data logging
- 8.6 Synchronization
- 8.7 Real-time acquisition
- 8.8 Serial and network interfaces
- 8.9 Data storage
- 8.10 Measurement validation
- 8.11 Verification and failure analysis
What does it take to turn a sensor, a converter and a microcontroller into an instrument whose readings can be trusted in a real laboratory?
Which few design decisions and tests dominate each common instrument — temperature, energy, speed, power quality, battery, calibration rig and test station?
9 sections · 6 figures
- 9.1 Temperature monitoring
- 9.2 Energy monitoring
- 9.3 Motor-speed measurement
- 9.4 Power-quality measurement
- 9.5 Battery monitoring
- 9.6 Sensor calibration systems
- 9.7 Automated test equipment
- 9.8 Laboratory data-acquisition systems
- 9.9 Verification and failure analysis
Part II built measurement chains that end in a number. This part puts a processor at the end of the chain and makes it act: drive a motor, join a network, and finally decide on its own what its sensors are telling it. Its three systems are a battery-powered radiator valve, a cold-chain monitoring fleet for 120 pharmacies, and a vibration node that classifies a water pump's condition. None of their field failures came from a broken part. A valve that emptied its batteries overnight, an alarm that never reached anyone and a classifier that called healthy pumps unbalanced all failed in the joins, at an assumption about a battery, a connection or a scale factor that was never written down and tested. Each chapter carries its system from requirements through budgets, component choice and implementation to verification, failure analysis and the revision the failures forced.
Part opener: part-3-embedded-and-connected-systems/README.md
How are a microcontroller, sensors, an actuator, a radio and a battery integrated into a device whose timing, energy and fault behaviour are designed rather than discovered?
What has to be measured, injected and recorded before an embedded product can be trusted to run unattended for years?
9 sections · 6 figures
- 10.1 The reference system: a battery-powered radiator valve
- 10.2 Microcontroller selection
- 10.3 Sensor and actuator interfaces
- 10.4 Firmware architecture
- 10.5 Timing constraints
- 10.6 Power management
- 10.7 Fault handling
- 10.8 Communication interfaces
- 10.9 Debugging and testing
11. IoT Systems
How is a fleet of connected devices designed so that data and alarms arrive complete, on time and authenticated, across links that fail silently?
Which choices of connectivity, protocol, storage, provisioning and security decide whether the system can be trusted for regulated records over five years?
10 sections · 6 figures
- 11.1 Requirements and device architecture
- 11.2 Connectivity
- 11.3 Telemetry
- 11.4 MQTT and HTTP fundamentals
- 11.5 Gateways
- 11.6 Data storage
- 11.7 Remote monitoring
- 11.8 Device provisioning
- 11.9 Authentication
- 11.10 Security, reliability and verification
When should data be turned into decisions on the device, and how is a learned model fitted into the memory, time and energy of a microcontroller?
How is an embedded model validated so that the number measured in the lab is the number seen in the field, and what does the device do when the model is wrong?
11 sections · 6 figures
- 12.1 The reference system: a pump condition-monitoring node
- 12.2 Edge versus cloud processing
- 12.3 Resource constraints
- 12.4 Data preprocessing
- 12.5 Sensor fusion
- 12.6 Model deployment
- 12.7 Quantisation
- 12.8 Inference performance
- 12.9 Memory and power constraints
- 12.10 Model validation
- 12.11 Failure handling and verification
A robot is where the rest of this book meets in one machine: sensors and acquisition from Part II, a microcontroller and firmware from Part III, motors and power electronics from the sibling books, and a mechanism that turns it all into force and motion. It is also where integration mistakes become physical: a shoulder sized at the wrong pose drops a tube, a wheel radius 1.5 % off sends a robot into a wall 60 m later, a bus with nowhere to put regenerated energy lets a robot roll down a ramp. Part IV calculates such failures before the build. Its systems are a six-axis laboratory arm, a hospital delivery robot and its motor-control board, a bridge-inspection quadcopter, and a collaborative assembly arm taken through integration and field test, each carried from requirements through budgets, part selection and implementation to verification, failure analysis and the second version the failures forced.
Part opener: part-4-robotics-and-mechatronics/README.md
How do a task and a bench turn into a robot architecture, a number of joints, a kinematic model and a set of joint actuators with known margins?
Where do the position errors and the torque peaks of a real arm come from, and how are they budgeted, verified and designed out before the robot meets a person?
10 sections · 5 figures
- 13.1 Robot architectures
- 13.2 Degrees of freedom
- 13.3 Coordinate frames
- 13.4 Forward kinematics
- 13.5 Inverse kinematics
- 13.6 Joint and Cartesian motion
- 13.7 Workspace
- 13.8 Actuator selection
- 13.9 Mechanical–electrical integration
- 13.10 Verification and failure analysis
14. Mobile Robotics
How does a wheeled robot know where it is, how wrong that knowledge becomes with every metre, and which sensors and calibrations keep the error inside a budget?
How are its motors, battery and obstacle sensors sized so that it climbs the ramp, lasts the shift and stops before it touches anyone?
11 sections · 5 figures
- 14.1 Requirements and architecture
- 14.2 Differential-drive robots
- 14.3 Wheel encoders
- 14.4 Line-following robots
- 14.5 Obstacle detection
- 14.6 Odometry
- 14.7 Path planning fundamentals
- 14.8 Localization
- 14.9 Navigation
- 14.10 Battery and motor sizing
- 14.11 Robot testing
Which drivers, interfaces, loops and timing turn a navigation computer's velocity commands into wheel motion that is accurate, fast and safe?
How are power distribution and fault recovery designed so that a full battery, a missing message or a stuck sensor ends in a controlled stop instead of a runaway?
12 sections · 6 figures
- 15.1 Requirements and architecture
- 15.2 Motor drivers
- 15.3 Encoder interfaces
- 15.4 Sensor fusion
- 15.5 Embedded controllers
- 15.6 PID implementation
- 15.7 Feedback loops
- 15.8 Timing and latency
- 15.9 Communication buses
- 15.10 Power distribution
- 15.11 Fault recovery
- 15.12 Verification and failure analysis
How are the motors, propellers, speed controllers, battery and flight controller of a multirotor sized together against a hover-time, thrust and stability requirement?
How is a flight-control stack made to work on a vibrating airframe, and how is a multirotor tested so that its first failure happens on the bench and not over a river?
10 sections · 6 figures
- 16.1 Multirotor architecture
- 16.2 Brushless motors
- 16.3 Electronic speed controllers
- 16.4 Propeller selection
- 16.5 Flight-controller architecture
- 16.6 IMUs
- 16.7 Attitude estimation
- 16.8 Flight-control loops
- 16.9 Battery sizing
- 16.10 Safety and testing
Which interfaces (mechanical, electrical, firmware, timing, power, communication) must be specified between the modules of a robot, and what numbers go into each specification?
How is an integrated robot calibrated, identified, tested in the loop and in the field so that its first system-level failure happens in the lab and not on a customer's line?
12 sections · 6 figures
- 17.1 The reference arm: requirements and architecture
- 17.2 Mechanical design interfaces
- 17.3 Electronics integration
- 17.4 Firmware
- 17.5 Control
- 17.6 Power distribution
- 17.7 Communication
- 17.8 Calibration
- 17.9 System identification
- 17.10 Hardware-in-the-loop testing
- 17.11 Field testing
- 17.12 Failure analysis and the second iteration
Factories, water works, quarries and process plants run on a layer of engineering the theory books mention only in passing: the controller that scans its inputs every 10 ms, the I/O drop that goes to a designed safe state when its network falls silent, the 4–20 mA loop whose voltage budget decides whether a reading is true, the drive that must stop a belt within 4 s, and the networks and safety systems that tie them together. This part designs that layer. It follows four real systems from requirement to commissioning: the control system of a 30 ML/day water-treatment works, the instruments and actuators of a dairy clean-in-place skid, the motor control of a quarry conveyor line, and the networks and safety functions of a palletising cell on a beverage line. The theory is taken from the books that own it; this part adds the architecture, the budgets, the real parts, the PLC code, the tests with their limits, and the failures each design had to survive.
Part opener: part-5-industrial-automation/README.md
How is an industrial control system partitioned into controllers, I/O, networks, operator stations and supervisory software, and how is each part sized?
How is the assembled system shown to work, at the factory and on site, before it is trusted with the plant?
9 sections · 5 figures
- 18.1 Industrial control systems
- 18.2 PLCs
- 18.3 Remote I/O
- 18.4 Distributed control systems
- 18.5 Supervisory control and data acquisition
- 18.6 Human-machine interfaces
- 18.7 Industrial networking
- 18.8 Control panels
- 18.9 System commissioning
How are industrial sensors, transmitters, valves, contactors, relays and actuators chosen against a requirement, and how is each one interfaced to a PLC without losing accuracy, speed or fail-safety?
Which budgets (loop voltage, uncertainty, sensing distance, coil energy, force, air) must be written down before the skid is built?
12 sections · 5 figures
- 19.1 The reference skid and its requirements
- 19.2 Proximity sensors
- 19.3 Limit switches
- 19.4 Industrial temperature sensors
- 19.5 Pressure transmitters
- 19.6 Flow measurement
- 19.7 Solenoid valves
- 19.8 Contactors
- 19.9 Relays
- 19.10 Pneumatic and hydraulic interfaces
- 19.11 Industrial motor actuators
- 19.12 Verification and failure analysis
How is each motor of a plant started, protected, controlled in speed, interlocked and stopped, and how are those choices traced to requirements?
What goes into the motor-control panel, and how is the whole line commissioned and proved, emergency stops included?
11 sections · 5 figures
- 20.1 The conveyor line and its requirements
- 20.2 Motor starters
- 20.3 Contactors
- 20.4 Overload protection
- 20.5 Variable-frequency drives
- 20.6 Speed regulation
- 20.7 Interlocks
- 20.8 Emergency stops
- 20.9 Fault monitoring
- 20.10 Control-panel design
- 20.11 Commissioning, verification and failure analysis
How are the field networks of a machine (Modbus, CAN-based networks, industrial Ethernet) chosen, sized and diagnosed so that their timing is a number written down before commissioning?
How is a safety function specified, built from certified parts, proven against ISO 13849-1, kept fail-safe over a network, and protected and documented so that it still works in year ten?
12 sections · 5 figures
- 21.1 The reference cell and its requirements
- 21.2 Fieldbus fundamentals
- 21.3 Modbus
- 21.4 CAN-based industrial networks
- 21.5 Industrial Ethernet
- 21.6 Network diagnostics
- 21.7 Functional safety fundamentals
- 21.8 Safety interlocks
- 21.9 Fail-safe behaviour
- 21.10 Industrial cybersecurity
- 21.11 Maintenance documentation
- 21.12 Verification and failure analysis
Part V built machines that consume electrical energy under control. This part builds the systems that produce, store and move it: a rooftop PV plant, the battery that stores its output, the electric vehicle that carries a battery on wheels, and the microgrid that makes PV, wind, storage, generators and the grid work as one. Almost every number in them is set by an environment the designer does not control — the coldest dawn of the decade, the hottest afternoon on a roof, a −10 °C delivery round, a feeder that trips at noon on a Sunday. Each chapter writes those extremes into its requirements, sizes strings, cells, converters and cables against them, budgets energy, voltage, temperature and current, and closes with tests against numbers fixed before the build.
Part opener: part-6-renewable-energy-and-electric-mobility/README.md
How is a PV system sized from the solar resource to the grid connection, so that every string, cable and protective device stays inside its limits on the coldest morning and the hottest afternoon?
How are its losses budgeted, its yield predicted and its performance proven after commissioning?
12 sections · 6 figures
- 22.1 Requirements and architecture
- 22.2 Solar resource assessment
- 22.3 PV module characteristics
- 22.4 String sizing
- 22.5 Inverters
- 22.6 MPPT
- 22.7 Battery integration
- 22.8 Protection
- 22.9 Cable sizing
- 22.10 System losses
- 22.11 Performance evaluation
- 22.12 Failure analysis
How is a battery pack architected, from cell choice and series–parallel configuration to contactors, fuses and the battery-management system, so that it delivers its rated energy and power safely over its whole life?
How are its state of charge, temperature and health measured well enough to keep that promise, and how is it tested before anyone is allowed near it?
11 sections · 6 figures
- 23.1 Requirements and pack architecture
- 23.2 Cell selection
- 23.3 Series and parallel configurations
- 23.4 Battery-management systems
- 23.5 State estimation
- 23.6 Thermal management
- 23.7 Charging
- 23.8 Protection
- 23.9 Degradation monitoring
- 23.10 Safety testing and verification
- 23.11 Failure analysis
How is an electric vehicle's powertrain sized from a duty cycle, and which component limits each requirement: range, gradeability, acceleration, charging time?
What must the vehicle, the charger and the depot agree on, electrically and thermally, so that the energy budget holds in winter and the fleet is recharged inside the site's power limit?
11 sections · 6 figures
- 24.1 EV architecture
- 24.2 Vehicle energy consumption
- 24.3 Traction motors
- 24.4 Inverters
- 24.5 DC–DC converters
- 24.6 Battery packs
- 24.7 Regenerative braking
- 24.8 Thermal constraints
- 24.9 Charging systems
- 24.10 Charging infrastructure
- 24.11 Verification, failure analysis and Revision B
How are PV, wind, storage and generators sized and dispatched together so that a site meets an energy target, a resilience target and a budget at the same time?
What must each inverter, relay and controller be set to do so that the system works both connected to the grid and as an island, and moves between the two without a blackout?
11 sections · 6 figures
- 25.1 Hybrid architectures
- 25.2 Load profiles
- 25.3 Solar–wind–storage integration
- 25.4 Energy management
- 25.5 Grid-connected operation
- 25.6 Islanded operation
- 25.7 Inverter coordination
- 25.8 Protection
- 25.9 Reliability
- 25.10 Economic evaluation
- 25.11 Verification, failure analysis and Revision B
Parts II–VI built systems that measure, compute, move and convert energy. This part follows the information they produce: across the air from a node to a gateway, through filters and detectors on an embedded processor, and from the most demanding measurement chain of all, one connected to a human body. The three chapters share one idea. A signal arrives with a budget against it: path loss and fading on a radio link, noise and interference in a sensor channel, electrode offset, mains pickup and leakage current on a patient. Each chapter writes that budget down per stage, closes it with a stated margin, and tests it in the configuration the system will really be used in.
Part opener: part-7-communications-signal-processing-and-biomedical/README.md
How is a wireless link designed so that its margin is known before installation, at every site, in the worst season and the worst location?
Which choices in the front end, antenna, gateway placement and protocol settle the trade between range, battery life, latency and reliability, and how is each one tested?
9 sections · 6 figures
- 26.1 RF front-end architecture
- 26.2 Antenna selection
- 26.3 Transceiver interfaces
- 26.4 Link budgets
- 26.5 Channel constraints
- 26.6 Wireless sensor networks
- 26.7 Communication reliability
- 26.8 Interference mitigation
- 26.9 System testing
How is a measurement chain designed so that what reaches the algorithms is the signal, not noise, aliases or artefacts of the processing itself?
How are features and detectors chosen for a specific fault mechanism, implemented in real time on an embedded processor, and proved against numbers written down before the build?
10 sections · 6 figures
- 27.1 Sensor-noise reduction
- 27.2 Filtering
- 27.3 Spectral analysis
- 27.4 Feature extraction
- 27.5 Event detection
- 27.6 Audio processing
- 27.7 Image processing
- 27.8 Real-time DSP
- 27.9 Embedded implementation
- 27.10 Performance evaluation
How is a biopotential front end sized for skin, electrode offsets and mains interference, and how is it proved to reject them?
What do patient safety, isolation and medical-device regulation demand of the architecture, the firmware and the test plan?
10 sections · 6 figures
- 28.1 Biopotential measurement
- 28.2 ECG acquisition
- 28.3 EMG acquisition
- 28.4 Biomedical sensors
- 28.5 Isolation and safety
- 28.6 Signal conditioning
- 28.7 Noise rejection
- 28.8 Medical data acquisition
- 28.9 Basic biomedical signal analysis
- 28.10 Regulatory and ethical considerations
Every chapter of this book ends in numbers, and most of them are computed before they are measured. Part VIII is about the software that produces them and the discipline that makes them trustworthy. It treats engineering computation as an engineering system in its own right, with requirements, budgets of time and error, tools chosen against alternatives, tests with limits and failures analysed to their mechanism. A number that cannot be regenerated, a solver result never checked against a known answer, a file format that silently changes old projects, a learned model scored on its training data, an uncalibrated twin: each is a defect as real as an undersized cable. Five running systems carry the method: the design workflow of a 48 V-to-12 V converter, the thermal optimisation of an inverter heatsink, a cable-sizing tool used by sixty engineers, machine-learning models built on engineering data, and a digital twin of a pump set.
Part opener: part-8-engineering-software-and-computational-tools/README.md
How is an engineering project organised so that requirements, models, simulations, measurements and reports stay linked and every result can be regenerated?
Which tools are used for which question, and how are they automated, tested and versioned without slowing the design down?
10 sections · 5 figures
- 29.1 Requirements and modeling
- 29.2 Numerical computation
- 29.3 Circuit simulation
- 29.4 System simulation
- 29.5 Version-controlled projects
- 29.6 Reproducible builds
- 29.7 Automated testing
- 29.8 Data import and export
- 29.9 Results visualization
- 29.10 Engineering documentation
How are numerical solvers, sweeps and optimisers chosen and combined so that a design computation is fast enough to explore the design space and accurate enough to decide on?
How is a computed result verified, validated against a measurement, and stored so that it can be trusted and reproduced a year later?
12 sections · 6 figures
- 30.1 The reference computation
- 30.2 Numerical solvers
- 30.3 Parameter sweeps
- 30.4 Optimization
- 30.5 Simulation automation
- 30.6 Data processing
- 30.7 Computational performance
- 30.8 Parallel processing
- 30.9 Verification of numerical results
- 30.10 Model validation
- 30.11 Scientific data management
- 30.12 Failure analysis of the computation
How is an engineering tool divided into a domain model, calculation services, persistence, plug-ins and user interfaces so that each can change without breaking the others?
How are project files, interfaces and tests designed so that a result computed today is reproduced, exchanged and still trusted ten years from now?
11 sections · 5 figures
- 31.1 The reference tool and its requirements
- 31.2 Modular software design
- 31.3 Domain models
- 31.4 File-based project formats
- 31.5 Plugin versus built-in architecture
- 31.6 APIs and interfaces
- 31.7 GUI design
- 31.8 Data interoperability
- 31.9 Version control
- 31.10 Automated testing
- 31.11 Long-term maintainability
How is machine learning applied to engineering data so that the model's error is known before deployment, including outside the conditions it was trained on?
Where do physics, data cleaning and honest evaluation matter more than the choice of algorithm, and what does a model need to run on a substation gateway?
12 sections · 6 figures
- 32.1 Engineering datasets
- 32.2 Data cleaning
- 32.3 Feature engineering
- 32.4 Regression
- 32.5 Classification
- 32.6 Time-series forecasting
- 32.7 Anomaly detection
- 32.8 Surrogate models
- 32.9 Physics-informed modeling
- 32.10 Model evaluation
- 32.11 Uncertainty
- 32.12 Deployment constraints
How is a physics model turned into a twin that tracks one particular machine: calibrated, fed with live data, estimating its own drifting parameters and validated against limits written down in advance?
How uncertain is a twin's prediction, and how is that uncertainty used to make a design or operating decision that will not be regretted?
10 sections · 6 figures
- 33.1 Physical-system models
- 33.2 Numerical simulation
- 33.3 Model calibration
- 33.4 Co-simulation
- 33.5 Digital-twin architectures
- 33.6 Real-time data integration
- 33.7 Parameter estimation
- 33.8 Validation
- 33.9 Uncertainty quantification
- 33.10 Simulation-based design
Parts I to VIII built the methods and the subsystems one at a time. Part IX puts them together. Each chapter is one complete project, carried from a problem statement to a tested system: requirements with IDs, an architecture, budgets with margins, real parts, design calculations, firmware or tool code, a test plan with limits, test results, a bill of materials with indicative cost, a failure analysis and a closing "Revision B" that says what the next iteration would change and why. The projects differ in kind (a fast mobile robot, a mains-connected instrument, an energy system, a motor drive, a radio network, a piece of engineering software, and the method for a capstone of the reader's own). Theory is not repeated: each chapter points back to the chapter that owns a method and to the sibling book that owns the physics, and spends its pages on integration decisions and on what went wrong in the first build.
Part opener: part-9-interdisciplinary-engineering-projects/README.md
Which sensor geometry, motor, gear ratio and control structure let a 170 g robot lap a 15 m track in under 10 s without leaving the line?
How are the timing, power and mass budgets written so that the robot that is built is the robot that was analysed?
10 sections · 6 figures
- 34.1 Requirements
- 34.2 Sensor selection
- 34.3 Motor selection
- 34.4 Circuit design
- 34.5 Embedded firmware
- 34.6 Control algorithm
- 34.7 Power budgeting
- 34.8 Testing
- 34.9 Performance optimisation
- 34.10 Revision B
How do a CT, a resistive divider and a 24-bit ADC become an energy measurement good to 1 % at power factor 0.5 and at 0.5 A?
How is a device that touches 230 V mains and talks to a home Wi-Fi network made safe, robust against outages and verifiable against a meter standard?
10 sections · 6 figures
- 35.1 Voltage and current measurement
- 35.2 Signal conditioning
- 35.3 Power calculations
- 35.4 Embedded processing
- 35.5 Data logging
- 35.6 Communications
- 35.7 Calibration
- 35.8 Safety
- 35.9 Validation
- 35.10 Bill of materials, failure analysis and Revision B
How is a stand-alone solar battery system sized so that it carries a critical load through the worst month and a run of cloudy days, and what does the sizing leave out?
Which converters, charge settings, protective devices and monitoring make that sizing true on site, and how is the finished system verified and costed?
10 sections · 5 figures
- 36.1 Load estimation
- 36.2 PV sizing
- 36.3 Battery sizing
- 36.4 Converter selection
- 36.5 Charge control
- 36.6 Protection
- 36.7 Monitoring
- 36.8 Efficiency
- 36.9 Economic assessment
- 36.10 Verification, failure analysis and Revision B
How is a closed-loop motor drive designed from measured motor parameters to loop gains, so that its bandwidth, accuracy and torque envelope are known before it is built?
Which sensing, firmware structure and protection make that design work on a real machine, and how is it tested, including when it is driven into faults?
8 sections · 6 figures
- 37.1 Motor characterization
- 37.2 Encoder integration
- 37.3 Power stage
- 37.4 Current and speed measurement
- 37.5 Controller design
- 37.6 Firmware
- 37.7 Protection
- 37.8 Performance testing
How are the sensors, radio, protocol and battery of a sensor node chosen together so that it delivers its data for five years on a cold night in full leaf?
How is a network of such nodes made reliable and secure, and how is it deployed and proven in the field?
8 sections · 5 figures
- 38.1 Sensor selection
- 38.2 Node architecture
- 38.3 Communication protocol
- 38.4 Power budgeting
- 38.5 Data acquisition
- 38.6 Network reliability
- 38.7 Security
- 38.8 Deployment and testing
How does an engineer turn a physical question into a simulation tool whose equations, solver, input checks and outputs all serve one design decision?
What evidence — verification, benchmarking, validation, documentation and reproducibility — makes a home-grown tool trustworthy enough to drop a heat sink from a production board?
10 sections · 5 figures
- 39.1 Problem definition
- 39.2 Governing equations
- 39.3 Numerical solver
- 39.4 Input validation
- 39.5 Visualization
- 39.6 Benchmarking
- 39.7 Verification
- 39.8 Documentation
- 39.9 Reproducible results
- 39.10 Project close-out: cost, test results, failure analysis and Revision B
How does a team choose a problem, learn what is already known, and turn a need into requirements, an architecture and a design that can be built and verified in one academic year?
How are cost, risk and schedule handled with numbers rather than hope, and how is all of it reported so that someone else could build, test and improve the result?
10 sections · 5 figures
- 40.1 Problem selection
- 40.2 Literature review
- 40.3 Requirements
- 40.4 Architecture
- 40.5 Detailed design
- 40.6 Implementation
- 40.7 Verification and validation
- 40.8 Cost analysis
- 40.9 Risk assessment
- 40.10 Final technical report
Applications and Integrations · Book 6 of the EEE series · Repository · PDF · MIT License · These pages are generated by scripts/make-wiki.mjs.
Applications and Integrations
Links