Automated Test Configuration Protocol

I. Automatic Test Platform File Structure and Function Description¶

File Path	Main Components	Function Description
`RflySimSDK`	`AutoMAVDB`	Test case library and data management library, supporting automated operations on databases/files
	`AutoMAVCmd`	Test sequence parsing, mapping high-level test sequences to control commands (e.g., MAVLink) to drive unmanned vehicles
	`AutoMAVCtrl`	Unmanned vehicle process management, including test environment configuration, task scheduling, and vehicle parameter settings
	`PX4MavCtrlV4`	Communication management module, encapsulating user commands into MAVLink messages for communication initialization and coordinated control
	`CameraCtrlApi` / `VisionCaptureApi`	Vision control and acquisition module, supporting operations such as configuring vision parameters and capturing image frames
`src/autotest/`	`AutoTest`	Main entry point for automated testing, enabling one-click configuration and execution of vehicle test tasks
`src/openSHA/`	`ProfitsSA/Ass`	Health and safety assessment algorithm library (e.g., rate-mode reliability), supporting online validation of customizable assessment models
`src/model/Quadrotor/`	`db.json`, `ModelHITL`, `ModelSITL`	Quadrotor model configuration and test case binding, supporting HITL and SITL simulations
`src/model/Fixedwing/`	Same structure as above	Fixed-wing aircraft model configuration, supporting the same multi-mode testing
`data/SITL/` and `data/HITL/`	`single/sInstance`, `multi/mInstance`, etc.	Automatically collects SITL/HITL simulation data, supporting four structural configurations: single/multi vehicle types and single/multi instances
`case/`	Database files (e.g., `case.db`)	Stores the UAV test case database; can also be visually edited via tools in the `tools` folder
`tools/`	`Navicat for SQLite`, etc.	Visual database configuration tools to simplify test case management
`docs/`	`Readme`, `Platform handbook`, etc.	Platform documentation, covering usage methods, architectural principles, and module interfaces

II. Standardized Control Sequence and Test Case Configuration Description¶

To achieve efficient and large-scale automated testing of unmanned systems, the RflySim automatic test platform adopts a standardized control instruction sequence protocol, expressing control logic in a structured, clear digital string format, and centrally managing and parsing it via the JSON configuration file db.json.

Control Sequence Protocol Structure¶

Each control instruction is comma-separated, with parameters listed in order, and terminated by a semicolon, representing a standardized action. Its structure is as follows:

Field Sequence	Description
`X` (first field)	Control category (time-based / control-based)
`Y` (second field)	Function number within the category
Subsequent fields	Input parameters for the function, listed in order

Control Categories and Function Numbers¶

Control Category	Function Number	Function Description	Example
`1` Time-based	`1`	Wait for duration: `Wait(times)`	`1,1,5` → Wait 5s
	`2`	Wait for reset: `WaitReset(pos)`	`1,2,0`
`2` Control-based	`1`	Arm: `Arm()`	`2,1`
	`2`	Disarm: `Disarm()`	`2,2`
	`3`	Position control: `FlyPos(x,y,z)`	`2,3,0,0,-20`
	`4`	Velocity control: `FlyVel(vx,vy,vz)`	`2,4,1,0,0`
	`5`	Land: `Land()`	`2,5`
	`6`	Fault injection: `FaultInject(params)`	`2,6,ID,...`

Example Interpretation¶

The control sequence is as follows:

2,1;1,1,5;2,3,0,0,-20;1,1,15;2,6,123450,123450,0.6,0.8,1,1;1,1,10

Analysis as follows:

Step	Instruction	Meaning Description
①	`2,1`	Unlock (Arm)
②	`1,1,5`	Wait for 5 seconds
③	`2,3,0,0,-20`	Fly to position `[0,0,-20]`
④	`1,1,15`	Wait for 15 seconds
⑤	`2,6,123450,123450,0.6,0.8,1,1`	Fault injection (here, motor fault; multiple parameters are included. One fault ID (123450) can correspond to only 2 fault parameters, so the fault ID is repeated twice here due to 4 parameters—see [Fault Injection Protocol] for details)
⑥	`1,1,10`	Wait for 10 seconds

Test Case JSON Configuration File Structure¶

{
  "FAULT_CASE": [
    {
      "CaseID": 1,
      "Subsystem": "Power",
      "Component": "Motor",
      "FaultID": "123450",
      "FaultType": "Motor Fault",
      "FaultMode": "Decreased efficiency of motor execution",
      "FaultParams": "0",
      "ControlSequence": "2,1;1,1,5;2,3,0,0,-15;1,1,10;2,6,123450,123450,1,1,1,1;1,1,10",
      "TestStatus": "Finished"
    },
    ...
  ],
  "TEST_CASE": "1,2",
  "VISION": "off"
}

Field Descriptions¶

【1】`FAULT_CASE`: Core test case configuration item, containing the following fields:¶

Field	Meaning
`CaseID`	Unique identifier (primary key) for the test case
`Subsystem`	Subsystem to which the fault belongs (e.g., Power, Sensor)
`Component`	Faulted component (e.g., Motor, Magnetometer)
`FaultID`	Fault identifier
`FaultType`	Description of fault type
`FaultMode`	Description of fault mode
`FaultParams`	Fault injection parameters
`ControlSequence`	Control flow string (formatted per the protocol above)
`TestStatus`	Current test status (e.g., Finished)

【2】`TEST_CASE`: Used for managing automatic test execution order¶

Single-vehicle mode:

Format: "1,2" (comma-separated in English) indicates sequential execution of test cases #1 and #2

To test all cases: set to "All"
Multi-vehicle mode:

Format: "1,2;1,3" indicates:

Round 1: Vehicle #1 executes case #1, Vehicle #2 executes case #2
Round 2: Vehicle #1 executes case #1, Vehicle #2 executes case #3
Different rounds are separated by semicolons (;), and vehicles within a round are separated by commas (,)

【3】`VISION`: Visual module switch (used for image acquisition interface)¶

"on": Enable camera image publishing
"off": Disable visual acquisition functionality