In my research I set out to rethink how a UAV drone intended for pipeline inspection should be conceived, modelled, verified and iterated. My starting point is a simple observation that has shaped every part of my work: the development of a modern UAV drone is no longer a single-discipline engineering exercise. It is a coupled problem in which the mission logic that lives in the information domain must remain continuously consistent with the rigid-body dynamics, aerodynamics, wind disturbance behaviour and closed-loop control that live in the physical domain. When these two domains are handled by separate teams, separate documents and separate tool chains, the result is a design process in which parameter mismatches are discovered late, trajectory requirements are disconnected from achievable dynamic responses, and every iteration consumes a physical prototype. I therefore propose an integrated design method in which Model-Based Systems Engineering (MBSE) supplies the formal information-domain backbone and multi-physics acausal modelling supplies the executable physical-domain counterpart, with the two connected through an explicit mapping mechanism inside a single simulation platform.
The application context I selected is the inspection of a long-distance industrial pipeline, a task that stresses a UAV drone in ways that are easy to underestimate. The UAV drone must climb to a safe inspection altitude, align itself with the pipeline axis, hold a controlled lateral offset while travelling roughly two hundred metres, trigger high-resolution imaging events at discrete points of interest, respond to terrain undulation, and still return safely when the mission terminates. Every one of these behaviours is simultaneously a systems-engineering artefact and a control-dynamics problem. My method treats them as such.
1. Motivation and the Two Failure Modes of Conventional Practice
From my reading of the literature and from the engineering practice I observed, the weaknesses of the traditional document-driven route to a UAV drone can be grouped into two failure modes. The first is a failure of association: the information domain describes objectives in prose, while the underlying design is expressed in geometry, electronics and control code. There is no unified model that binds the two, so the task logic of the UAV drone and its dynamic response cannot be expressed in one place. The second is a failure of dynamic representation: the physical behaviour of the UAV drone is judged by human experience and by repeated physical prototype testing, which limits the achievable reliability of the power-system coupling and slows every design cycle.
I wanted a method that removes both failure modes at once. MBSE removes the first by replacing documents with formal, traceable models of requirements, behaviour, function, structure and parameters. Unified multi-domain modelling removes the second by replacing prototype iteration with a solvable, physically grounded simulation model. Table 1 summarises the contrast I use to justify my design philosophy.
| Aspect | Document-driven development | Integrated MBSE-driven development |
|---|---|---|
| Primary carrier of design intent | Text documents and drawings | Formal models with consistent semantics |
| Traceability from mission to parameter | Weak, frequently broken | Explicit and machine-checkable |
| Representation of UAV drone dynamics | Empirical judgement plus prototype tests | Executable multi-physics simulation |
| Coupling of information and physical domains | Manual, informal and intermittent | Structured mapping and closed-loop linkage |
| Iteration cost | High, dominated by hardware builds | Low, dominated by model re-execution |
| Verification coverage before first flight | Limited to subsystem level | Full mission profile simulated end to end |
| Adaptability to a new mission scenario | Requires partial redesign | Re-parameterisation of the existing model |
2. The Modelling Foundations I Adopted
MBSE in my work rests on three pillars: a methodology that organises the engineering flow, a modelling language that gives the flow a formal vocabulary, and a tool environment that executes and stores the models. I evaluated the available methodologies before committing, and Table 2 records that evaluation.
| Methodology | Core idea | Suitability for a UAV drone programme |
|---|---|---|
| Harmony | Behaviour-driven functional decomposition following a V-shaped flow, embedding software and systems engineering in one process | High, because mission behaviour of the UAV drone naturally drives functional decomposition |
| OOSEM | Object-oriented analysis with top-down functional decomposition and strong hardware/software integration | Moderate to high, but heavier emphasis on software architecture than on physical dynamics |
| OPM | Unified object-process representation with a single diagram type for structure and behaviour | Moderate, valuable for consistency but less natural for multi-domain simulation hand-off |
I selected Harmony because its behaviour–function–structure–parameter chain mirrors precisely the way a UAV drone mission unfolds: the UAV drone first exhibits behaviour, that behaviour demands functions, the functions are allocated to a physical architecture, and the architecture is finally constrained by quantitative parameters. For the modelling language I adopted SysML, which provides the diagram set I need without forcing me into software-specific constructs. For the environment I used a Harmony-based systems modelling tool for the information domain and a Modelica-based multi-domain platform for the physical domain.
2.1 The SysML diagram set I use
My information-domain model is assembled from a deliberately chosen subset of SysML diagrams. Requirements diagrams capture the stakeholder-facing obligations of the UAV drone and the derivation links between them. Use-case diagrams fix the system boundary and express the mission as a set of named capabilities connected by include relationships. Activity diagrams carry the control flow, the decision nodes and the merge nodes that describe how the UAV drone transitions from one mission phase to the next. Block definition diagrams and internal block diagrams establish the static architecture and the interface structure. Parametric diagrams bind quantitative attributes through constraint blocks. Table 3 lists the mapping I use between modelling intent and diagram choice.
| Modelling intent | SysML diagram | What it delivers for the UAV drone |
|---|---|---|
| Stakeholder obligations and their decomposition | Requirement diagram | Traceable levels of mission, system and component requirements |
| System boundary and capability set | Use-case diagram | A clean separation between the UAV drone and external actors |
| Mission sequencing and control logic | Activity diagram | Branching, iteration and termination conditions of the inspection mission |
| Static architecture and interfaces | Block definition and internal block diagrams | Subsystem composition and signal/energy interfaces of the UAV drone |
| Quantitative consistency | Parametric diagram | Mass, geometry and performance constraints enforced on the architecture |
3. Structure and Operating Principles of the UAV Drone
Before any model can be built I must be precise about what the UAV drone physically is. My reference platform is a four-rotor configuration with a symmetric frame, a flight controller, four brushless motors with electronic speed controllers, a lithium battery, four propellers and a set of auxiliary sensing devices. Two geometric arrangements dominate practice: the cross configuration and the X configuration. I adopt the configuration in which the arms are aligned with the body axes because it simplifies the decomposition of roll and pitch authority and makes the mapping from motor-speed commands to body moments more transparent.
The subsystems of my UAV drone are grouped as follows. The airframe carries and connects everything else and determines the mass distribution that enters the rotational dynamics. The propulsion group converts electrical energy into thrust and constitutes the actuation path of the UAV drone. The flight-control group senses attitude, angular rate, position and altitude, and computes the actuation commands. The communication group links the UAV drone to the ground operator. The auxiliary group provides obstacle awareness, localisation support and payload control. Table 4 summarises these groups and the interface each one exposes to the rest of the system.
| Subsystem group | Principal components | Interface exposed | Role in the mission |
|---|---|---|---|
| Airframe | Frame, arms, mounting plates, shell | Mechanical mounting points | Structural integrity and mass distribution |
| Propulsion | Motors, propellers, speed controllers, battery | Thrust and torque to the airframe | Generates all control authority of the UAV drone |
| Flight control | Processor, inertial unit, satellite receiver, barometer, magnetometer | Actuation commands and state estimates | Stabilisation and guidance |
| Communication | Receiver, telemetry link, ground terminal | Command and telemetry frames | Mission upload and status downlink |
| Auxiliary | Obstacle sensors, navigation aids, illumination, landing protection | Perception and payload signals | Safety and mission quality |
3.1 Motion principles
All translational and rotational motion of the UAV drone emerges from the imbalance of the four rotor thrusts. Vertical motion follows from the sum of thrusts relative to weight; pitch follows from the fore–aft thrust difference; roll follows from the lateral thrust difference; yaw follows from the differential reaction torque of the counter-rotating pairs. Because roll, pitch and yaw are produced by differential authority rather than by dedicated control surfaces, the UAV drone is an underactuated system with four inputs and six degrees of freedom, and this underactuation is exactly what makes the coupling between information-domain commands and physical-domain response non-trivial.
4. Information-Domain Modelling of the Inspection Mission
I began the information-domain work by planning the inspection mission itself. The pipeline segment of interest lies between two endpoints, and the UAV drone must acquire the segment, align with it, traverse it, and return. I divided the mission into a preparation phase, an autonomous inspection phase and a termination phase, and I deliberately introduced intermediate waypoints so that the transition between free flight and inspection flight is gradual rather than abrupt. This waypoint structure is what later allows me to express the mission as a sequence of differentiable functions rather than as a list of discontinuous jumps.
4.1 Stakeholder and boundary analysis
The stakeholders I identified for the UAV drone mission are the pipeline operating organisation, the design organisation and the maintenance organisation. Their concerns are respectively inspection throughput and detection quality, engineering feasibility and architectural extensibility, and serviceability with standardised interfaces. The external actors in the operational context are the ground operator and the satellite navigation system. This analysis fixes the system boundary and prevents the UAV drone model from absorbing responsibilities that belong to the ground segment.
4.2 Requirements decomposition
From the mission analysis I derived a three-branch top-level requirement set and then refined it into a second level. Table 5 records the top-level requirements and Table 6 the second-level decomposition. I use this two-level structure because it maps naturally onto the behaviour–function split: the top level states what the UAV drone must be capable of in operational terms, and the second level states the functional obligations that the architecture must satisfy.
| Identifier | Requirement | Level |
|---|---|---|
| 0.1 | The UAV drone shall possess operational capability | 1 |
| 0.2 | The UAV drone shall possess cruise capability | 1 |
| 0.3 | The UAV drone shall possess contingency handling capability | 1 |
| Identifier | Second-level requirement | Level |
|---|---|---|
| 1.1 | The UAV drone shall perform pre-flight preparation | 2 |
| 1.2 | The UAV drone shall perform a controlled take-off | 2 |
| 1.3 | The UAV drone shall perform a controlled return | 2 |
| 1.4 | The UAV drone shall maintain a stable hover | 2 |
| 1.5 | The UAV drone shall respond through its actuation chain | 2 |
| 1.6 | The UAV drone shall respond through its flight-control loop | 2 |
| 2.1 | The UAV drone shall estimate its relative position | 2 |
| 2.2 | The UAV drone shall exchange command and telemetry data | 2 |
| 2.3 | The UAV drone shall detect the pipeline and its surroundings | 2 |
| 2.4 | The UAV drone shall plan its inspection path | 2 |
| 2.5 | The UAV drone shall follow the pipeline track | 2 |
| 2.6 | The UAV drone shall adapt to terrain undulation | 2 |
| 3.1 | The UAV drone shall handle attitude anomalies | 2 |
| 3.2 | The UAV drone shall handle cruise anomalies | 2 |
| 3.3 | The UAV drone shall handle altitude anomalies | 2 |
| 3.4 | The UAV drone shall handle insufficient energy | 2 |
| 3.5 | The UAV drone shall handle loss of communication | 2 |
| 3.6 | The UAV drone shall handle sudden meteorological events | 2 |
| 3.7 | The UAV drone shall handle interruption of the inspection task | 2 |
| 3.8 | The UAV drone shall handle adverse weather conditions | 2 |
4.3 Behavioural modelling
I expressed the mission behaviour with use-case and activity models. The use-case model treats the whole inspection task as the top-level use case and decomposes it into capability-level use cases linked by include relationships, each corresponding to a distinguishable phase of the UAV drone flight. The activity model then specifies the internal control flow: after task release, a decision node tests whether the UAV drone satisfies the execution preconditions; if it does, the flow proceeds through climb and cruise; a further decision node evaluates mission completion; and the flow terminates either normally or through an abort branch. This separation is important to me because it keeps the information-domain model declarative while leaving the quantitative behaviour to the physical domain.
4.4 Structural and parametric modelling
The internal block diagram of my UAV drone places the airframe at the centre of the mechanical composition, hosts the flight controller as the computational core, and attaches the navigation and perception modules through signal ports. The path-planning function supplies the controller with a reference trajectory and a target list, and the controller in turn drives the actuator chain that sets rotor speeds. This structure makes the allocation of functions to physical elements explicit, which is what allows me to hand a well-formed interface specification to the physical-domain modelling step.
The parametric layer closes the loop between architecture and numbers. My central constraint is the mass budget, which I express as an equality between the system-level mass attribute and the sum of the component masses:
$$
m_{\text{total}} = m_{\text{frame}} + 4\,m_{\text{rotor}} + 4\,m_{\text{motor}} + m_{\text{avionics}} + m_{\text{battery}} + m_{\text{payload}}
$$
A second constraint compares the computed total mass against the design allowance:
$$
g_{\text{mass}} : \quad m_{\text{total}} \le m_{\text{allowance}}
$$
By embedding these expressions as constraint blocks and binding them to the corresponding value properties, I obtain a parametric diagram in which any change of a component mass immediately propagates to the system-level verdict. In my workflow this is the point at which a static architectural decision becomes a quantitative, checkable statement about the UAV drone.
5. Physical-Domain Modelling of the UAV Drone
The physical domain is where my method earns its keep. I chose an acausal, equation-based modelling language because it allows mechanical, aerodynamic, environmental and control submodels to be connected by conserved quantities rather than by forced input–output causality. Each component declares connector variables and behavioural equations, and the platform assembles the overall differential-algebraic system automatically.
5.1 Coordinate frames and transformation
I use two frames. The inertial frame has its origin at a fixed ground point, with the horizontal axes aligned to the cardinal directions and the vertical axis opposed to gravity. The body frame has its origin at the centre of mass of the UAV drone, with the longitudinal axis pointing forward, the lateral axis completing a right-handed set, and the vertical axis pointing downward. Position and velocity are naturally expressed in the inertial frame, whereas forces and moments are naturally expressed in the body frame, so a transformation between the two is unavoidable.
The elementary rotations about the three body axes are:
$$
R(\phi)=\begin{bmatrix}1&0&0\\0&\cos\phi&\sin\phi\\0&-\sin\phi&\cos\phi\end{bmatrix}
$$
$$
R(\theta)=\begin{bmatrix}\cos\theta&0&-\sin\theta\\0&1&0\\\sin\theta&0&\cos\theta\end{bmatrix}
$$
$$
R(\psi)=\begin{bmatrix}\cos\psi&\sin\psi&0\\-\sin\psi&\cos\psi&0\\0&0&1\end{bmatrix}
$$
Composing the three elementary rotations gives the body-to-inertial transformation, which I write in the form used throughout my model:
$$
R_B^{E}=R(\psi)R(\theta)R(\phi)=
\begin{bmatrix}
\cos\theta\cos\psi & \sin\phi\sin\theta\cos\psi-\cos\phi\sin\psi & \cos\phi\sin\theta\cos\psi+\sin\phi\sin\psi\\
\cos\theta\sin\psi & \sin\phi\sin\theta\sin\psi+\cos\phi\cos\psi & \cos\phi\sin\theta\sin\psi-\sin\phi\cos\psi\\
-\sin\theta & \sin\phi\cos\theta & \cos\phi\cos\theta
\end{bmatrix}
$$
The inverse transformation is simply the transpose, which is convenient for converting measured body-frame accelerations back into the inertial frame.
5.2 Rigid-body dynamics
I model the UAV drone as a rigid body with a diagonal inertia tensor and with the centre of mass coincident with the body-frame origin. I neglect elastic deformation of the rotors and arms, ignore higher-order aerodynamic effects such as rotor-wake interference and aeroelastic coupling, and treat each rotor thrust as proportional to the square of its rotational speed. Under these assumptions the total external force acting on the UAV drone is the sum of the rotor thrust, gravity and aerodynamic drag:
$$
\sum \mathbf{F} = \mathbf{F}_{B}^{E} + \mathbf{F}_{g} + \mathbf{F}_{f}
$$
The thrust produced by an individual rotor follows the quadratic law:
$$
F_i = C_L N_i^2, \qquad i = 1,2,3,4
$$
so that the total body-frame thrust and its inertial-frame representation are:
$$
F_B = \sum_{i=1}^{4} F_i, \qquad \mathbf{F}_{B}^{E} = R_B^{E}\begin{bmatrix}0\\0\\F_B\end{bmatrix}
$$
Gravity acts along the negative vertical direction and drag is modelled as a linear function of velocity, which is adequate for the low-speed inspection regime I consider:
$$
\mathbf{F}_{g}=\begin{bmatrix}0\\0\\-mg\end{bmatrix}, \qquad
\mathbf{F}_{f}=-\begin{bmatrix}K_x\dot{x}\\K_y\dot{y}\\K_z\dot{z}\end{bmatrix}
$$
Assembling these contributions gives the translational equations of my UAV drone model:
$$
\begin{cases}
\ddot{x} = \dfrac{F_B}{m}\left(\cos\phi\sin\theta\cos\psi+\sin\phi\sin\psi\right) – \dfrac{K_x}{m}\dot{x}\\[6pt]
\ddot{y} = \dfrac{F_B}{m}\left(\cos\phi\sin\theta\sin\psi-\sin\phi\cos\psi\right) – \dfrac{K_y}{m}\dot{y}\\[6pt]
\ddot{z} = \dfrac{F_B}{m}\cos\phi\cos\theta – g – \dfrac{K_z}{m}\dot{z}
\end{cases}
$$
For the rotational motion I define the control torques generated by differential rotor thrust and differential reaction torque:
$$
U_2 = (F_4-F_2)L, \qquad U_3 = (F_3-F_1)L, \qquad U_4 = d\left(-N_1^2+N_2^2-N_3^2+N_4^2\right)
$$
The rotational equations then read:
$$
\begin{cases}
\dot{p} = \dfrac{I_y-I_z}{I_x}qr – \dfrac{K_\phi}{I_x}p – \dfrac{J_r}{I_x}qN + \dfrac{U_2}{I_x}\\[6pt]
\dot{q} = \dfrac{I_z-I_x}{I_y}pr – \dfrac{K_\theta}{I_y}q + \dfrac{J_r}{I_y}pN + \dfrac{U_3}{I_y}\\[6pt]
\dot{r} = \dfrac{I_x-I_y}{I_z}pq – \dfrac{K_\psi}{I_z}r + \dfrac{U_4}{I_z}
\end{cases}
$$
where the rotor-speed sum entering the gyroscopic term is
$$
N = -N_1+N_2-N_3+N_4
$$
Taken together, the translational and rotational equations form the six-degree-of-freedom model that I implemented in my physical-domain component. Table 7 lists the parameter values I used in the simulation study.
| Symbol | Quantity | Value | Unit |
|---|---|---|---|
| \(m\) | Total mass of the UAV drone | 1.25 | kg |
| \(L\) | Rotor-to-centre distance | 0.38 | m |
| \(R\) | Rotor radius | 0.16 | m |
| \(J_r\) | Rotor inertia | 1 | kg·m² |
| \(I_x\) | Roll moment of inertia | 0.096 | kg·m² |
| \(I_y\) | Pitch moment of inertia | 0.096 | kg·m² |
| \(I_z\) | Yaw moment of inertia | 0.016 | kg·m² |
5.3 Wind disturbance environment
A UAV drone inspecting an industrial pipeline rarely flies through still air, so I treated the wind field as a first-class subsystem rather than as an afterthought. I decompose the wind into a slowly varying mean component and a stochastic turbulence component, and I superpose the two because the underlying descriptions are linear.
The mean wind is represented by a logarithmic profile that accounts for surface roughness:
$$
\bar{W}(h) = W_{ref}\,\frac{\ln\!\left(h/z_0\right)}{\ln\!\left(h_{ref}/z_0\right)}
$$
For the turbulence component I adopt the Dryden spectral description, whose power spectral densities along the three body axes are:
$$
\Phi_u(\omega)=\frac{2\sigma_u^2 L_u}{\pi V}\cdot\frac{1}{1+\left(L_u\omega/V\right)^2}
$$
$$
\Phi_v(\omega)=\frac{\sigma_v^2 L_v}{\pi V}\cdot\frac{1+3\left(L_v\omega/V\right)^2}{\left[1+\left(L_v\omega/V\right)^2\right]^2}
$$
$$
\Phi_w(\omega)=\frac{\sigma_w^2 L_w}{\pi V}\cdot\frac{1+3\left(L_w\omega/V\right)^2}{\left[1+\left(L_w\omega/V\right)^2\right]^2}
$$
The corresponding shaping filters that convert unit-variance white noise into a coloured turbulence signal are:
$$
H_u(s)=\sigma_u\sqrt{\frac{2L_u}{\pi V}}\cdot\frac{1}{1+\left(L_u/V\right)s}
$$
$$
H_v(s)=\sigma_v\sqrt{\frac{L_v}{\pi V}}\cdot\frac{1+\left(\sqrt{3}L_v/V\right)s}{\left[1+\left(L_v/V\right)s\right]^2}
$$
$$
H_w(s)=\sigma_w\sqrt{\frac{L_w}{\pi V}}\cdot\frac{1+\left(\sqrt{3}L_w/V\right)s}{\left[1+\left(L_w/V\right)s\right]^2}
$$
For low-altitude operation I scale the turbulence length scales and intensities with height according to the relations:
$$
L_w = 2h, \qquad L_u=L_v=\frac{0.177+0.000823h}{1.2}
$$
$$
\sigma_w = 0.1\,W_{ref}, \qquad \sigma_u=\sigma_v=\frac{\sigma_w}{\left(0.177+0.000823h\right)^{0.4}}
$$
The total wind velocity in each body axis is then the sum of the mean and turbulent parts:
$$
V_{xx}=\bar{v}_{xx}+u_d, \qquad V_{yy}=\bar{v}_{yy}+v_d, \qquad V_{zz}=\bar{v}_{zz}+w_d
$$
5.4 Rotor aerodynamics under wind
Wind changes the induced velocity at the rotor disc, and therefore changes both the effective thrust and the reaction torque of each rotor of the UAV drone. I define the induced velocity from momentum theory and combine it with the local wind component:
$$
V_d = \sqrt{\frac{F_i}{2\rho A}}, \qquad V = V_d + V_w
$$
so that the resultant aerodynamic force and reaction torque of a rotor become:
$$
F_{ri}=F_i+F_{wi}=2\rho A V_d V, \qquad M_R = M_i + M_{wi} = K_R V^2
$$
This treatment is deliberately compact, but it captures the essential first-order mechanism by which a gust produces a thrust perturbation on the UAV drone and thereby excites the attitude loop.
5.5 Control system
I use a control architecture in which a geometric line-of-sight law generates the heading reference and a proportional–integral–derivative structure regulates the attitude and the altitude. The line-of-sight law converts a lateral deviation into a heading correction:
$$
\psi_d = \psi_p – \arctan\!\left(\frac{e_y}{\Delta}\right)
$$
where \(e_y\) is the signed cross-track error between the UAV drone and the reference track, and \(\Delta\) is the look-ahead distance that trades tracking tightness against heading oscillation. The discrete proportional–integral–derivative law that acts on the resulting errors is:
$$
u(k)=K_p e(k)+K_i\sum_{i=0}^{k}e(i)+K_d\left[e(k)-e(k-1)\right]
$$
I cascade this law across four loops of the UAV drone: an altitude loop that commands collective thrust, and three attitude loops that command the roll, pitch and yaw moments. Table 8 states the role of each loop.
| Loop | Controlled variable | Actuation channel | Primary disturbance source |
|---|---|---|---|
| Altitude | Vertical position | Collective thrust | Vertical wind component, mass uncertainty |
| Roll | Roll angle | Lateral thrust difference | Lateral gust, asymmetric drag |
| Pitch | Pitch angle | Longitudinal thrust difference | Longitudinal gust, acceleration transients |
| Yaw | Heading angle | Reaction torque difference | Cross-track error, turbulence |
6. Multi-Physics Simulation Results
With the physical-domain components assembled and connected, I executed two families of simulation cases for the UAV drone: an undisturbed case that establishes the baseline dynamic quality, and a disturbed case in which the wind model is active. Both cases follow the same mission profile so that the comparison is fair.
6.1 Undisturbed response
In the undisturbed case the attitude angles of the UAV drone exhibit a short transient at the beginning of the mission and then converge rapidly. The roll and pitch excursions peak near 0.25 rad and decay to within a few hundredths of a radian within roughly five to ten seconds, which tells me that the damping inherent in the model and the controller gains are well matched. The yaw angle starts with a small offset of about 0.12 rad and converges asymptotically to zero with no residual oscillation. Around the mission-switching instant I observe a transient in roll and pitch that decays within about ten seconds and does not compromise the overall stability of the UAV drone.
The body-frame velocity components behave in the same reassuring way. All three components show a brief transient during the take-off interval, with a longitudinal peak near 5 m/s, a lateral peak near 4 m/s and a vertical excursion below 1 m/s. During the steady inspection cruise the longitudinal velocity settles near 3 m/s while the lateral and vertical components are suppressed to nearly zero, which is precisely the behaviour I want from the UAV drone while the imaging payload is active. After the mission switch at around sixty seconds the longitudinal velocity reverses, reaching about −5 m/s, the lateral velocity oscillates with a peak near 3 m/s, and the vertical component again remains small. Every one of these excursions recovers within about ten seconds.
6.2 Wind-disturbed response
When I activate the wind model, the UAV drone still completes the mission, but the signatures change in instructive ways. The initial transient in roll and pitch grows to about 0.25 rad and 0.30 rad respectively, driven by the simultaneous onset of the gust field and the large initial control effort. The yaw angle stays within roughly 0.1 rad of its reference during this stage. During the mid-mission interval the pitch response becomes the most sensitive channel, reaching approximately −0.35 rad, while roll reaches about −0.25 rad. The yaw angle steps from roughly 0.12 rad to 0.25 rad and stabilises without meaningful overshoot, which tells me that the heading loop of the UAV drone retains its authority even when the disturbance is strong.
The velocity response shows the same structure. The longitudinal component peaks near 5.5 m/s before settling at 3 m/s, the lateral component shows a bounded oscillation with a peak near 4 m/s, and the vertical component stays close to zero throughout. The recovery time after the mid-mission disturbance extends to roughly ten to fifteen seconds, noticeably longer than in the undisturbed case, but the steady-state error remains zero and no variable diverges. Table 9 summarises the comparison.
| Quantity | Undisturbed case | Wind-disturbed case | Interpretation |
|---|---|---|---|
| Peak roll excursion | ≈0.25 rad | ≈0.25 rad initial, ≈0.25 rad mid-mission | Roll authority preserved |
| Peak pitch excursion | ≈0.25 rad | ≈0.30 rad initial, ≈0.35 rad mid-mission | Pitch is the most gust-sensitive channel |
| Yaw offset | 0.12 rad decaying to zero | 0.12 rad to 0.25 rad step, then constant | Heading loop retains authority |
| Longitudinal velocity peak | ≈5 m/s | ≈5.5 m/s | Modest increase under gust loading |
| Lateral velocity peak | ≈4 m/s | ≈4 m/s | Bounded oscillation, no drift |
| Settling time after disturbance | ≈10 s | ≈10 s to 15 s | Longer but still acceptable |
| Steady-state error | Zero | Zero | No bias introduced by the gust field |
What I take from this comparison is that the gust field enlarges the transient amplitude and lengthens the settling time of the UAV drone, but it does not alter the qualitative stability of the system. That is exactly the behaviour a designer should be able to observe before committing to a hardware build, and it is the reason I insist on keeping the environmental subsystem inside the executable model rather than treating it as a post-hoc uncertainty.
7. Integrated Mission-Level Design and Simulation
The final part of my work connects the two domains into a single executable mission. I represent the state of the UAV drone as a vector that concatenates position, velocity, attitude and angular rate:
$$
Z(t)=\begin{bmatrix}X(t) & V(t) & \Theta(t) & \omega(t)\end{bmatrix}^{T}
$$
and I write the continuous evolution as:
$$
\dot{Z}(t)=f\!\left(Z(t),U(t)\right)
$$
On top of this continuous core I superimpose the discrete inspection events. The pipeline itself is described by a spatial distribution over its length, and the points of interest are represented by localised functions that become active when the UAV drone reaches them:
$$
\Gamma=\int_{0}^{S} r(s)\,ds, \qquad \eta(t)=\sum_{i=1}^{N}\delta\!\left(X(t)-P_i\right)
$$
To keep the resulting system numerically tractable I replace the idealised impulse by a smooth kernel:
$$
\delta_{\vartheta}(d)=\frac{1}{\sqrt{2\pi}\,\vartheta}\exp\!\left(-\frac{d^2}{2\vartheta^2}\right)
$$
The overall inspection task quality can then be written as a single functional that mixes the continuous coverage requirement with the discrete event requirement:
$$
J_{\text{task}}\!\left(X(t)\right)=\int_{0}^{T}\left[\omega_{\Gamma}\,\Gamma\!\left(X(t)\right)+\sum_{i=1}^{N}\omega_i\,\delta_{\vartheta}\!\left(X(t)-P_i\right)\right]dt
$$
This expression is important to me because it places continuous flight and discrete event triggering inside one mathematical object. The controller of the UAV drone can therefore be evaluated against a single mission-level criterion rather than against a collection of loosely related subsystem targets.
7.1 Terrain and scenario modelling
Because I target a mountainous pipeline corridor, the ground surface must be represented as a height field that combines smooth relief with sharp features:
$$
h(x,y)=h_s(x,y)+h_c(x,y)+h_r(x,y)
$$
The smooth component captures the large-scale undulation:
$$
h_s(x,y)=a\sin\!\left(y+bx\right)+c\cos\!\left(dxy\right)+e\sin\!\left(fy\right)+gx\cos\!\left(hy\right)
$$
The cliff component uses a smoothed Heaviside function so that a vertical escarpment is representable without introducing a discontinuity into the numerical problem:
$$
h_c(x,y)=H_{\epsilon}\!\left(g_c(x,y)\right), \qquad H_{\epsilon}(u)=\frac{1}{2}\left(1+\tanh\!\left(\frac{u}{\epsilon}\right)\right)
$$
The ridge and valley component uses a smoothed line distribution:
$$
h_r(x,y)=\alpha\,\delta_{\epsilon}\!\left(r_g(x,y)\right)
$$
with \(\alpha>0\) producing ridges and \(\alpha<0\) producing valleys. Feeding this terrain description into the path-planning function of my information-domain model closes the loop between the environment and the mission logic of the UAV drone.
7.2 Coupled execution of the two domains
The integration mechanism works as follows. The information-domain model decides what the UAV drone should be doing at each mission instant: whether it is climbing, cruising, imaging or returning. The physical-domain model receives the resulting commands and integrates the equations of motion, producing position, velocity and attitude. Those state variables are fed back to the mission logic, which uses them to evaluate transition conditions. The coupling is therefore bidirectional, and neither domain can be executed in isolation without losing meaning.
I evaluated the coupled execution along three projections. In the horizontal plane the UAV drone begins with a lateral adjustment that settles into a constant offset from the pipeline axis and then holds that offset for the duration of the inspection leg. Near the end of the leg the trajectory bends smoothly into the return geometry. In the vertical plane the UAV drone climbs quickly, settles at its inspection altitude, holds that altitude with small ripple during the long cruise, and then executes a commanded altitude change at the mission switch. In the full three-dimensional view the trajectory appears piecewise smooth with localised adjustments, which is the signature I expect when continuous flight dynamics are combined with discrete mission events.
7.3 Control performance at mission level
Altitude holding is the first performance indicator I examine, because the imaging quality of the UAV drone depends directly on it. The altitude response shows a rapid climb, a short settling interval and then a stable plateau at approximately 2.25 m. Over the first one hundred and fifty metres of the inspection leg the altitude ripple remains small, which I attribute to the altitude loop successfully rejecting both the vertical wind component and the coupling from attitude transients. At the mission switch the commanded altitude changes to roughly 3.25 m, and the response shows a brief undershoot followed by a damped recovery. The oscillation decays within a few seconds, and the steady-state error returns to zero.
The attitude response tells a complementary story. Immediately after take-off the pitch angle of the UAV drone rises sharply to a few radians because the vehicle is still accelerating and the attitude coupling has not yet been resolved by the controller. Convergence is rapid, and thereafter the pitch excursions remain small throughout the inspection leg. At the mission switch near one hundred and fifty metres the pitch angle again shows a short oscillation before re-converging. Across the whole mission the amplitude of pitch variation stays modest and the response never exhibits sustained oscillation, which is the condition I require for stable sensor pointing.
Table 10 collects the mission-level indicators I use to judge whether the integrated design is acceptable.
| Indicator | Observed behaviour | Design implication |
|---|---|---|
| Horizontal track convergence | Settles to a constant lateral offset on the inspection leg | The UAV drone can hold a fixed stand-off distance from the pipeline |
| Altitude plateau stability | Small ripple around the commanded altitude over a long leg | Imaging geometry remains consistent |
| Altitude re-trim at mission switch | Damped excursion followed by zero steady-state error | The altitude loop accommodates commanded changes |
| Pitch excursion magnitude | Short transient at take-off, small thereafter | Sensor pointing is not disturbed during inspection |
| Trajectory smoothness | Piecewise smooth with localised transitions | Continuous dynamics and discrete events coexist without conflict |
| Boundedness under disturbance | All state variables remain bounded in every case | No divergence risk within the modelled envelope |
8. What the Integrated Method Delivers
Bringing the two domains together produced a design capability that neither domain could provide alone. The information-domain model guarantees that every requirement of the UAV drone is connected to a function, that every function is allocated to an architectural element, and that every architectural element is constrained by a quantitative parameter. The physical-domain model guarantees that those parameters produce the dynamic behaviour that the mission actually needs. The mapping between them guarantees that a change on either side is visible on the other side without manual intervention.
I want to emphasise three consequences that I consider the most valuable outcomes of my study. First, the behaviour-to-parameter chain is complete and traceable, so a late requirement change propagates deterministically rather than by recollection. Second, the wind-disturbed simulation demonstrates that the environmental envelope of the UAV drone can be explored before any hardware exists, which converts a costly prototyping question into a cheap computational one. Third, the mission-level coupling of continuous flight and discrete inspection events demonstrates that the same model can serve both as a design artefact and as a verification artefact, which is the essential promise of a model-based approach.
My conclusions can be summarised in the form of the design loop that the method establishes:
$$
\text{Scenario} \rightarrow \text{Behaviour} \rightarrow \text{Function} \rightarrow \text{Structure} \rightarrow \text{Parameter} \rightarrow \text{Multi-physics response} \rightarrow \text{Verification} \rightarrow \text{Scenario}
$$
Every arrow in this chain corresponds to a modelled relationship rather than to a document hand-off, and that is precisely what distinguishes the integrated route from the conventional one.
9. Limitations and Directions I Intend to Pursue
I am conscious that my study has boundaries. The environmental model I used captures mean wind and Dryden turbulence but does not attempt to represent precipitation, thermal gradients or complex terrain-induced flow separation. The aerodynamic treatment of the rotors is first-order and does not include wake interaction between rotors on the same UAV drone. The terrain model is analytic and therefore smooth by construction, which is convenient for simulation but necessarily a simplification of a real mountainous corridor.
There are also opportunities I have deliberately left open. The closed loop between architecture and simulation could be extended so that simulation results not only verify a design but actively drive parameter optimisation for the UAV drone. The physical-domain model could be enriched with higher-fidelity local submodels in selected regions, retained inside the same system-level framework so that the fidelity gradient does not break the coupling. And the entire method could be validated against hardware-in-the-loop benches and, eventually, against flight tests, so that the credibility of the UAV drone model is established against measured data rather than against internal consistency alone.
Table 11 records the gap between what I have demonstrated and what I intend to demonstrate.
| Dimension | Current state | Intended extension |
|---|---|---|
| Environmental modelling | Mean wind plus Dryden turbulence | Precipitation, thermal effects, terrain-induced separation |
| Rotor aerodynamics | First-order momentum theory | Rotor-to-rotor wake interaction for the UAV drone |
| Terrain representation | Analytic smooth plus smoothed sharp features | Measured digital elevation data |
| Design loop closure | Simulation verifies architecture | Simulation drives automatic parameter optimisation |
| Validation basis | Internal consistency and physical plausibility | Hardware-in-the-loop and flight-test correlation for the UAV drone |
10. Closing Remarks
My work began from the conviction that a UAV drone intended for a demanding inspection mission deserves a design process as integrated as the vehicle itself. By building an information-domain architecture with MBSE and pairing it with an executable multi-physics model of the same vehicle, I obtained a single coherent representation in which mission logic, functional allocation, structural composition, parametric constraint, rigid-body dynamics, wind disturbance and closed-loop control all coexist and can be exercised together. The undisturbed and wind-disturbed studies confirmed that the resulting model reproduces the qualitative and quantitative behaviour I expect from a UAV drone of this configuration, and the mission-level study confirmed that continuous flight and discrete inspection events can be executed inside one coupled framework.
I regard the method as a viable technical route for scenario-specific UAV drone development. It does not remove the need for engineering judgement, and it does not remove the need for flight testing, but it does relocate a substantial part of the design exploration from the workshop to the model, and in doing so it makes the path from mission requirement to verified behaviour both faster and more transparent.