Cyber-physical systems postgraduate personal statement example

Personal statement example

My final-year project was meant to be straightforward: control the temperature of a small insulated chamber using a heater, a fan and two sensors. It became far more interesting once I moved the controller off the board and onto a Raspberry Pi communicating over Wi-Fi. The loop that had been comfortably stable suddenly overshot, because packets arrived late and occasionally not at all. I spent several weeks reading about delay in sampled-data control and eventually implemented a simple timestamped scheme where the controller discarded stale measurements and held its last output rather than acting on old data. The rig worked, but what stayed with me was the realisation that the network was now part of the plant. That idea — that computation, communication and physical dynamics have to be designed together rather than in sequence — is what draws me to postgraduate study in cyber-physical systems.

My degree gave me the separate pieces. Control systems taught me state-space models, stability margins and observer design; embedded systems gave me C on microcontrollers, interrupts, timers and the discipline of working within limited memory. A digital communications module covered modulation and error control, though largely in isolation from any physical process being controlled. Reading around the subject has helped me see where the joins are. Lee and Seshia's Introduction to Embedded Systems was particularly useful in showing how models of computation, from finite-state machines to dataflow, can be treated with the same seriousness as differential-equation models of the physical world. I have also been working through material on formal verification of hybrid systems, and while I am not yet fluent with reachability tools, I understand why proving safety properties matters when software decides how a machine moves.

Outside the degree, two things have kept me building. I restore and automate model railway layouts, which sounds unrelated until you try to run several trains on shared track with block occupancy detection. I use inexpensive current sensors and a microcontroller to detect which sections are occupied and enforce interlocking rules so that two trains cannot be given the same block. Debugging a false detection caused by electrical noise on a long run of track taught me more about sensor reliability than any lecture. Separately, I helped my uncle put together a monitoring setup for the irrigation on his allotment plot: a soil moisture probe, a solar-charged battery, a cheap radio link to a receiver in his shed, and a log he can check before deciding whether to water. It has failed in ordinary ways — condensation, a flat battery in December, a probe reading nonsense after a frost — and each failure has made me think harder about how systems behave when their assumptions quietly stop holding.

I currently work part-time as a technical assistant in a teaching laboratory, preparing equipment and helping second-year students with oscilloscopes, power supplies and their first microcontroller assignments. Explaining why a circuit is not behaving as expected has sharpened my own diagnostic habits, and managing the setup for sessions of thirty students has taught me to be organised and honest about what I do not know.

I would like the master's to give me stronger foundations in networked control, real-time scheduling and verification, together with substantial project work on a system that has to be both safe and practical. In the longer term I want to work on control and instrumentation for infrastructure — water networks, energy systems or transport — where the physical consequences of software decisions are immediate and the engineering has to be trustworthy rather than merely clever.