Develop and Verify a Quadcopter System Architecture

Since R2026a

This example shows an end-to-end workflow for verifying a simple quadcopter design using a model-based systems engineering (MBSE) approach, incorporating requirements engineering, system architecture, design implementation, and requirements verification. In this example, you will learn how to define requirements, create a system architecture, implement the design, and verify that the quadcopter follows predefined waypoints.

To open the project, enter this command.

openProject("VerificationBasedMBSE");

Specify Requirements for Quadcopter Design and Trajectory

Use Requirements Toolbox™ to author requirements in the Requirements Editor (Requirements Toolbox). If necessary, you can also import requirements from a Word (.docx), Excel® (.xlsx), or ReqIF file to Requirements Toolbox. For more information, see Import Requirements from Third-Party Applications (Requirements Toolbox).

• The conops.slreqx requirement set contains high-level requirements, including Surveillance Capability, Communications Capability, Imaging Capability, and UAV Capability.

• The uav.slreqx requirement set contains detailed requirements for the quadcopter, including Aircraft Performance, Power System, Mass Properties & Geometry, Flight Control System, Payload, and Image Processing.

• The gcs.slreqx requirement set contains details of Operator Interface.

Requirements are organized into parent and child requirements to improve testing at the verification stage.

Author System Architecture of Quadcopter Design

You can use System Composer™ to develop a system architecture from the project requirements.

Describe System Behavior Using Activity Diagrams

You can use an activity diagram to describe the flow of data through actions to validate functional system design. For more information, see Describe System Behavior Using Activity Diagrams. To open the activity diagram, use this command.

open("QuadSearchandRescue.slx");

The activity diagram shows the overall flow of the system architecture of quadcopter following the waypoints. The token represents the sequential phases which gets accomplished by the quadcopter as it advances.

The activity diagram is a functional flow representation of the events that occur in the quadcopter architecture model.

Describe Structure of Quadcopter Architecture Model

To open the QuadArchitecture.slx architecture model, in the Project tab, under Shortcuts, select QuadSystemArchitecture.

The architecture comprises of components, ports, and connectors that provides a clear representation of the relationships between interfaces and components. The quadcopter system architecture has three main components and their respective subsystems. The AirVehicle component represents the quadcopter model, which processes the input commands from a Ground Control Station, and transmits its state and telemetry essential for the quadcopter to track the predefined waypoints. The Visualization component is modeled to show the results of the simulation.

• The GroundControlStation component is responsible for sending custom operator commands to the vehicle in operation.

• The AirVehicle component receives operator commands or instructions from the Ground Control Station (GCS) and provides the UAV’s state.

• The Visualization component helps visualize the quadcopter behavior that tracks the waypoints.

The AirVehicle component consists of two subcomponents, FCS and VehicleModel, which process the operator commands as input to provide the UAV state as output.

• The Flight Control Station (FCS) component, which processes operator commands, consists of three subcomponents, ModeLogic, Guidance, and FeedbackControl.

  • The ModeLogic component determines and implements the quadcopter mode based on the operator command.

  • The Guidance component determines the relative position from the waypoints and the UAV state.

  • The FeedbackControl component outputs the control command to the vehicle model or quadcopter for processing.

• The VehicleModel component receives control commands and provides the UAV state for visualization.

To expand the architecture models, use the stereotypes applied to the components to record property values. For more information, see Define and Style Stereotypes in Profiles.

Design Quadcopter Components and Model Behaviors

To design the quadcopter components and model behavior, Simulink®, Stateflow®, and UAV Toolbox™ licenses are required. Each subcomponent of the quadcopter is linked to a Simulink behavior model, which describes the system.

The GroundControlStation component represents the ground control station (GCS).

• The GCS sends the operator commands OperatorCmds to control the quadcopter and receives telemetry data reporting its status and performance.

• Quadcopter mission modes are set as OnGround = 0, Takeoff = 1, Landing = 2, and EmergencyOff = 3.

• Landing command to the quadcopter is fed from GCS.

• The QuadData.sldd file is used to manage and store data for the models. For more information, see Architectural Data Editor.

The AirVehicle component represents the quadcopter model. It comprises of FCS and Vehicle Model sub-components. Mode logic, Guidance, and Feedback Control forms the integral part of FCS. Mode logic implements the quadcopter mode based on the operator command. The operator command provides MissionMode, whose default value is 1 (Flying) to determine the mode of the quadcopter.

The Guidance model represents the guidance system. Pre-defined waypoints are fed as a reference. The relative position error is calculated from the difference between the waypoints and the observed position of the quadcopter.

The FeedbackControl model represents the feedback control system, which provides the control commands to the vehicle model. Quadcopter mode is the control input, that determines the port to be selected as output. Roll, Pitch, YawRate, and Thrust are the variables used.

Roll, Pitch, YawRate and Thrust is assumed to be zero when quadcopter is at OnGround or in EmergencyOff mode. The relative position error is fed as an input to the PID controller, PID_Loops. When the quadcopter is in Takeoff mode (flying), the PID controller regulates the control input variables Roll, Pitch, Yaw Rate, and Thrust. During this process, YawRate is maintained at zero to ensure stable heading and to accurately track waypoints.

The VehicleModel component implements the quadcopter. A simple guidance model from UAV Toolbox is used to model the dynamics of the quadcopter. It calculates the UAV state from the control command. Altitude is negative, as the WorldPosition is considered in NED frame. The starting point of the quadcopter is set to [0,0,-0.15]. Simulation will stop once the quadcopter lands after tracking the waypoints.

Implement Visualization Quadcopter Path Using UAV Animation Block

The Visualization component visualizes the quadcopter following pre-defined waypoints by receiving the UAVState data and animating the quadcopter. For more information, see UAV Animation (UAV Toolbox).

Set these UAV Animation block parameters:

• Number of UAVs: 1

• UAV Type: Multirotor

• UAV size: 1

• UAV mesh color: [1 0 0]

• UAV mesh and trajectory alpha: 1

• Select Always open output figure at start of simulation

• Plot axis limits: [-Inf Inf;-Inf Inf;-Inf Inf]

• Max number of samples per trajectory: 100000

• Inertial frame in z-axis direction: Down

• Rotation format: Quaternion

• Sample time: -1

Simulate Quadcopter and View Design Implementation Results

To simulate the flight path of the quadcopter, click Run.

The quadcopter finally lands on ground level.

System Verification for Quadcopter Flight System

You can use Simulink Test™ to test and verify the requirements for a low-fidelity system, such as this quadcopter. For more information, see Verify Requirements by Using Tests (Requirements Toolbox).

To inspect or modify the Path Followed test, load the test and open the test manager using these commands.

sltest.testmanager.load('QuadcopterTests.mldatx');
sltest.testmanager.view

The tests show the movement of the quadcopter based on whether it follows the path according to the UAV Fly Patterns requirement. To check whether the quadcopter follows the given waypoints, click Run.

For advanced validation concepts, see Validating Quadcopter Requirements and System Architecture with Simulation.

Creating Digital Thread Using Data Traceability

You can use the Requirements Manager (Requirements Toolbox) to view the bidirectional traceability between the architecture, design, and test cases and the project requirements. You can also link requirements to associated components to maintain traceability between these artifacts. To open the Requirements Manager, in the lower-right corner of the canvas, in the Requirements toolbar, select Enter perspective. From there, you can view the details of the requirements file used in the model. You can also drag requirements onto components in the architecture model canvas to establish links. Once linked, a rectangular box displays on the top right corner of the component header.

You can also link requirements to test cases. The Requirements Editor (Requirements Toolbox) displays the requirements and the test cases to which they are linked. To view this information, right-click any requirement in the Requirements Manager and select Show in Requirements Editor.

You can also use a traceability diagram to trace requirements back and check that tests verify the requirements. From the Requirements Editor, navigate to Analysis > Traceability Diagram.

Summary

The quadcopter system architecture example uses System Composer to illustrate a model-based systems engineering workflow. You decompose the quadcopter into key components, define their ports and interfaces, and build a hierarchical model. You link requirements directly to architectural elements with Requirements Toolbox, ensuring traceability and consistency throughout the design.

You allocate Simulink behaviors to System Composer components to connect high-level architecture with detailed simulation models. By simulating and testing the integrated model, you confirm that system behavior meets requirements. The tools in this example allow you to collaborate, track changes, and iterate efficiently, making this workflow ideal for complex, multidisciplinary projects. Linking requirements and verifying design early helps you reduce integration risks and improve overall design quality.