The development of flight control systems for civilian Unmanned Aerial Vehicles (UAVs) presents significant challenges. These systems are characterized by stringent requirements for high reliability, safety, and deterministic real-time performance. They involve complex interactions with numerous external sensors and actuators, demanding precise timing and scheduling. Traditional document-driven development methodologies often fall short, as they lack formal mechanisms to describe and analyze non-functional properties—such as timing constraints, schedulability, and resource consumption like stack memory—early in the design lifecycle. Discovering violations of these critical properties during later integration or testing phases leads to costly rework and delays.
To address these challenges, model-driven development (MDD) has emerged as a superior paradigm. By creating a precise, analyzable model of the system during the architectural design phase, potential errors can be identified and corrected before any code is written. While modeling languages like UML have been used to capture functional requirements, they are inadequate for modeling hardware platform details and rigorously specifying the non-functional attributes essential for embedded real-time systems.
This is where the Architecture Analysis and Design Language (AADL) excels. AADL is a standardized, textual and graphical language specifically designed for modeling the architecture of performance-critical, embedded, real-time systems. It provides first-class constructs for both software components (processes, threads, subprograms, data) and execution platform components (processors, memories, buses, devices), allowing for a holistic system view. Crucially, AADL supports the specification of component properties, such as execution time, deadline, period, and priority, enabling early, automated analysis of system qualities. This paper explores the application of AADL to the modeling and, more importantly, the pre-implementation analysis of a civilian UAV flight control system, with a particular focus on schedulability, end-to-end data latency, and—through a novel extension—stack memory consumption.
Introduction to AADL Core Concepts
AADL models a system as a hierarchy of interacting components. The key component categories are:
- Software Components:
thread(concurrent unit of execution),thread group(logical grouping of threads),process(protected address space containing threads),data, andsubprogram. - Execution Platform Components:
processor(schedules threads),memory,bus, anddevice(representing sensors/actuators). - System Components:
system, used to assemble and encapsulate software and platform components into a composite hierarchy.
Components interact through well-defined interfaces: ports (for data/event flow) and features. Connections are explicitly defined between these interfaces. AADL’s power lies in its property sets, which allow the attachment of quantitative or qualitative values to components, connections, and other model elements to define their non-functional behavior. For example, a thread can have properties like Period => 10 ms, Compute_Execution_Time => 2 ms .. 3 ms, and Dispatch_Protocol => Periodic.
The language also supports modes to model dynamic architectural reconfiguration at runtime, and behavior annexes to specify detailed state machine behavior within components. This rich feature set makes AADL ideal for capturing the architecture of a complex civilian UAV flight control system.
Modeling the Civilian UAV Flight Control System
We adopt a top-down, incremental refinement approach to model the civilian UAV’s avionics system. This promotes a clean, understandable architecture that is amenable to analysis.
Top-Level System Architecture
The root system model, UAV_Avionics_System, integrates the software application with its underlying hardware execution platform. The software system (Flight_Control_Software) contains all application threads and is bound to the main flight control processor. The hardware system (Execution_Platform) models the physical resources: the processor, various peripheral devices (GPS receiver, ground communication unit, sensors, etc.), memory, and the buses (e.g., RS-232, serial, analog) that connect them. Devices are connected to the processor via specific bus types, modeling the physical communication pathways. This clear separation allows for analysis of binding and deployment implications.
The mapping between key AADL components and the physical civilian UAV system is summarized below:
| AADL Component Name | UAV System Element | Communication Protocol |
|---|---|---|
| Ground_Comm_Rx_Unit | Ground Communication Receiver | Serial (UART) |
| GPS_Sensor_Device | GPS Module | Analog Signal / UART |
| Ground_Controller_Device | Ground Control Station | RS-232 |
| Flight_Control_Processor | Main Flight Computer (e.g., ARM Cortex) | N/A |
| IMU_Sensor_Device | Inertial Measurement Unit | SPI / I2C |
Software Architecture Modeling
The Flight_Control_Software system component encapsulates the core application logic. It is structured into functional subsystems corresponding to major operational modes of the civilian UAV:
- Initialization & Self-Test Module: Performs system checks upon power-up.
- Ground Preparation Module: Handles pre-flight checks, sensor calibration, and initial navigation calculations.
- Flight Control Module: The main operational module executing stabilization, navigation, and guidance algorithms during autonomous flight.
- Payload Module (e.g., for rain seeding): Manages specialized mission equipment.
Each module is modeled as a thread group containing several individual thread components. For instance, the Ground Preparation Module (Ground_Prep_Thread_Group) contains threads for GPS data reception, ground command reception, initial navigation calculation, and telemetry data sending. Modes (initialization, ground, flight, payload_activation) and mode transitions model the high-level operational state changes of the civilian UAV, triggered by specific events or commands from the ground control station.
Detailed Behavior Modeling with Subprograms
To refine the design further, the internal logic of complex threads is modeled using AADL subprogram components and their call sequences. Consider the “Initial Calculation” thread within the Ground Preparation Module. Its algorithm involves calculating attitude angles, determining quaternion initial values or performing quaternion updates based on a condition, and finally computing initial velocity.
This procedural logic is modeled by creating subprogram components like Attitude_Angle_Calc, Quaternion_Init_Calc, Quaternion_Update, and Velocity_Calc. Their execution order and conditional calls can be specified using either a Behavior Annex state machine within the thread or by leveraging mode transitions internal to the thread. The subprogram call hierarchy forms a critical foundation for the subsequent stack memory analysis of the civilian UAV’s software.
Property Set Extension for Stack Analysis
While AADL provides excellent support for timing analysis, its standard property sets lack specific properties for estimating stack memory consumption—a crucial resource constraint in memory-constrained civilian UAV embedded systems. Traditional stack analysis occurs late, during or after implementation, or relies on wasteful over-allocation. To enable early-stage stack analysis at the model level, we define a new AADL property set: StackAnalysis_Properties.
This extension introduces properties to declare the expected memory footprint of various software elements. These properties can be applied to threads, subprograms, and other components, specifying size ranges (in bytes, kilobytes, etc.).
| Property Name | Description | Applies To |
|---|---|---|
| Local_Variables_of_Task_Size | Stack space for a thread’s local variables. | thread, subprogram |
| Return_Address_of_Function_Size | Space needed to store a return address on the stack during a subprogram call. | subprogram |
| Local_Variables_of_Function_Size | Stack space for a called subprogram’s local variables. | subprogram |
| Code_Size_of_Function | Size of the subprogram’s executable code (relevant for certain memory layouts). | subprogram |
| Context_of_Int_Size | Space to save processor context during an interrupt. | processor, device |
| Nested_of_Int_Size | Additional context space for nested interrupts (if applicable). | processor, device |
By annotating the civilian UAV flight control model with these properties, we create a foundation for automated calculation of worst-case stack usage for each thread and the system as a whole.
Analysis Algorithms and Verification
The true value of an AADL model lies in its ability to be analyzed. We focus on three key analyses for the civilian UAV system: schedulability, end-to-end data latency, and stack usage.
Model Information Access Framework
All analyses begin by extracting relevant information from the AADL model instance. We employ a Model-View-Controller (MVC) inspired framework where a model accessor traverses the graphical or textual model view. The controller interprets these queries, locates the corresponding elements in the abstract syntax tree of the model, and retrieves the necessary property values (e.g., thread periods, execution times, stack property values). This decoupled architecture allows analysis tools to be independent of the specific model editor.
Schedulability Analysis
Schedulability analysis determines whether all periodic and sporadic threads in the civilian UAV flight control system will meet their deadlines under a given scheduling policy (e.g., Rate Monotonic Scheduling – RMS). In RMS, priorities are assigned inversely to period: the shorter the period, the higher the priority.
A set of $n$ periodic threads is schedulable under RMS if the total CPU utilization $U$ is below a theoretical bound:
$$ U = \sum_{i=1}^{n} \frac{C_i}{T_i} \leq n(2^{\frac{1}{n}} – 1) $$
where $C_i$ is the worst-case execution time (WCET) and $T_i$ is the period of thread $i$. For large $n$, the bound approaches $\ln(2) \approx 0.693$. A more precise necessary and sufficient test is the **Response Time Analysis**.
The response time $R_i$ of thread $i$ is the longest time from its release to its completion:
$$ R_i = C_i + \sum_{j \in hp(i)} \left\lceil \frac{R_i}{T_j} \right\rceil C_j $$
where $hp(i)$ is the set of threads with higher priority than $i$. This equation is solved iteratively. The thread set is schedulable if $\forall i, R_i \leq D_i$ (its deadline, often equal to $T_i$).
The analysis tool calculates these values based on the Period, Compute_Execution_Time, and Priority properties in the model. If a thread is found to be unschedulable, the modeler can adjust these properties (e.g., optimize execution time, adjust period) early in the design of the civilian UAV software.
End-to-End Data Latency Analysis
This analysis computes the time taken for data to traverse a predefined functional path (flow in AADL) through the system, from a source (e.g., a sensor input) to a sink (e.g., an actuator output or a data log). This is vital for verifying that the civilian UAV’s control loops operate within required timeframes.
A flow’s latency is the sum of the contributions from its source component, its sink component, and all components and connections along the path:
$$ FlowLatency = \sum flow\_source + \sum flow\_path + \sum flow\_sink $$
Each component’s contribution is defined by its Compute_Execution_Time property. Connection delays can be specified via properties like Transmission_Time on bus access or port connections.
Given a required latency constraint $[L_{min}^{req}, L_{max}^{req}]$, the analysis verifies that the calculated flow latency $[L_{min}^{calc}, L_{max}^{calc}]$ and the actual summed execution time $[E_{min}^{calc}, E_{max}^{calc}]$ satisfy:
$$ E_{max}^{calc} \leq L_{max}^{calc} \leq L_{max}^{req} $$
$$ E_{min}^{calc} \leq L_{min}^{calc} \leq L_{min}^{req} $$
Violations indicate that the design of that civilian UAV functional path must be revised to meet timing requirements.
Stack Memory Analysis Algorithm
Our novel stack analysis algorithm operates on a call-tree derived from the AADL model. The tree is constructed from model components (threads, subprograms as nodes) and their containment/call relationships (as edges). Each node is annotated with the relevant stack size properties from our extended property set.
Let a node $v$ have a data structure containing its relevant stack size ranges and metadata:
$$ Struct_v = \{ LVTS, CallNum, Depth, RS, MD \} $$
For a subprogram node, $LVTS$ is replaced by $LVFS$ (Local_Variables_of_Function_Size), and we also store $RAFS$ (Return_Address_of_Function_Size) and $CSF$ (Code_Size_of_Function). $CallNum$ is its invocation count, $Depth$ is its depth in the tree, $RS$ is the aggregated stack size of its child nodes, and $MD$ is its operating mode.
The total stack size $TotalSize(M)$ for a mode $M$ of a parent node (e.g., a thread) is the maximum of two components: the size needed for its own direct children executing in that mode, and the maximum size needed by any subprogram call chain originating from it in that mode.
$$ TotalSize(M) = \max\left( \sum_{k \in Children\_NonSub(M)} F_k, \quad \max_{s \in Children\_Sub(M)} (S_s) \right) $$
where for a non-subprogram child $k$ (e.g., a contained data component or thread group):
$$ F_k = LVTS_k + RS_k $$
and for a called subprogram child $s$:
$$ S_s = LVFS_s + RAFS_s + CSF_s + \max_{c \in Calls(s)} (S_c) $$
The total stack requirement for a thread is the maximum $TotalSize(M)$ across all its operational modes. The overall system stack requirement is the sum of the requirements for all independently stacked threads (considering RTOS task stacks).
If the calculated worst-case stack size $S_{max}^{calc}$ exceeds the available memory $M_{avail}$, an adjustment algorithm is employed. It identifies the component on the critical path (contributing most to $S_{max}^{calc}$) with the smallest invocation count and greatest depth, suggesting its stack property ranges are the most efficient to optimize. The modeler then refines the estimated size ranges for that component in the civilian UAV model and re-runs the analysis iteratively until $S_{max}^{calc} \leq M_{avail}$.
Application and Verification on the Ground Preparation Module
We demonstrate the analysis on the Ground Preparation Module of our civilian UAV model. This module contains four main threads with the following properties:
| AADL Thread | Purpose | Period ($T_i$) | WCET ($C_i$) | Priority |
|---|---|---|---|---|
| GPS_Receiver_T | Reads GPS data | 4 ms | 1.0 ms | 1 (Highest) |
| Ground_Cmd_Receiver_T | Reads ground commands | 1 ms | 0.5 ms | 2 |
| Initial_Calc_T | Performs navigation init | 3 ms | 0.2 ms | 6 |
| Telemetry_Sender_T | Sends data to ground | 4 ms | 1.0 ms | 9 (Lowest) |
Schedulability Verification
Initial RMS utilization: $U = \frac{1.0}{4} + \frac{0.5}{1} + \frac{0.2}{3} + \frac{1.0}{4} = 0.25 + 0.5 + 0.067 + 0.25 = 1.067$. This exceeds the Liu & Layland bound for 4 tasks (~0.756), indicating a potential problem. Response Time Analysis reveals that the low-priority Telemetry_Sender_T (period 4ms, WCET 1ms) is preempted by all higher-priority tasks. Within its 4ms period, it only gets ~0.6ms of continuous execution, causing it to miss its deadline. The model must be adjusted. By optimizing code estimates, we reduce Ground_Cmd_Receiver_T WCET to 0.3ms and Telemetry_Sender_T WCET to 0.7ms. Recalculated utilization becomes $U = 0.25 + 0.3 + 0.067 + 0.175 = 0.792$. While still above the Liu & Layland bound, detailed Response Time Analysis now confirms all threads meet their deadlines, validating the schedulability of the adjusted civilian UAV software design.
Data Latency Verification
We analyze the flow from the GPS sensor through the GPS_Receiver_T thread to the Initial_Calc_T thread. Suppose the flow specification requires a latency in $[2.0, 3.0]$ ms. Model properties specify: flow source (sensor read & package) $[1.5, 2.0]$ ms, connection delay $[0.02, 0.03]$ ms, flow sink (calculation) $[0.5, 0.6]$ ms. The calculated flow latency is $[2.02, 2.63]$ ms, which is within the required bound. However, the sum of the actual thread WCETs on this path is $1.0 + 0.2 = 1.2$ ms (using initial values). The analysis flags that the specified source latency ($[1.5, 2.0]$ ms) is pessimistic compared to the actual thread execution ($1.0$ ms). The property can be refined to $[1.0, 1.2]$ ms for greater accuracy, demonstrating how the model guides requirement refinement for the civilian UAV system.
Stack Analysis Verification
We annotate the Initial_Calc_T thread and its called subprograms (Attitude_Angle_Calc, Quaternion_Update, etc.) with stack size properties from our extended set. The algorithm builds the call tree and computes the total stack requirement for this thread. Assume the total calculated stack range is $[101, 158]$ bytes. If the available memory for this task’s stack is only 150 bytes, the maximum value (158 bytes) violates the constraint. The adjustment algorithm identifies the subprogram with the widest estimated size range and lowest call count as the best candidate for optimization. By refining its Local_Variables_of_Function_Size property from, say, $[10, 20]$ bytes to a tighter $[10, 15]$ bytes and recalculating, the total stack range might become $[101, 149]$ bytes, which is now feasible. This process allows the civilian UAV software architect to allocate stack sizes confidently before implementation.
Conclusion
This exploration demonstrates the significant advantages of applying AADL to the design of civilian UAV flight control systems. By creating a formal architectural model that encompasses both software and hardware elements, and by extending the language with domain-specific properties for stack analysis, we enable the early verification of critical non-functional properties. Schedulability analysis prevents missed deadlines that could cause instability. End-to-end latency analysis ensures control loops operate within safe time bounds. Early stack memory analysis prevents overflows and optimizes resource usage in the typically constrained memory environment of a civilian UAV.
The model serves as a “single source of truth” that guides downstream development and implementation, ensuring consistency and reducing integration errors. Future work will focus on integrating more sophisticated analyses, such as incorporating the effects of mutual exclusion protocols (semaphores) on schedulability, modeling detailed interrupt handling routines, and refining the stack analysis to account for compiler-specific behaviors. The ultimate goal is to provide a comprehensive, model-driven engineering framework that enhances the reliability, safety, and development efficiency of increasingly autonomous civilian UAV systems.