You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Purpose: Implementation specification for an Unmanned Aircraft System (UAS / БАС). This document defines components, interfaces, data flows, and constraints so that another agent or team can implement the system.
External medium for data to/from the UAS (Среда передачи данных).
Communication Module with ATM
ATM_Comms
Interface between DTE and UAS for Air Traffic Management (ОрВД).
1.2 Top-Level Container
UAS (БАС): Contains all on-board systems. All components described below reside inside the UAS boundary unless stated otherwise.
2. Component Catalog
2.1 Communication Layer
2.1.1 Communication Module with UAS (Модуль связи с БАС)
Attribute
Value
Role
Manages communication with internal UAS components.
Inputs
Data from Data Transmission Environment (via external link).
Outputs
Data to: Navigation System; Autopilot (control/telemetry, dashed); Mission (Operator) (control/telemetry, dashed).
Interface note
Dashed links imply control or telemetry rather than raw sensor stream.
Implementation requirements:
Accept external data from DTE.
Route/fan-out to: Navigation System, Autopilot, Mission (Operator).
Define clear message schemas and topics/channels for each consumer.
2.2 Navigation
2.2.1 Navigation System (Система навигации)
Attribute
Value
Role
Provides position and navigation state.
Inputs
Data from Communication Module with UAS.
Outputs
Navigation data to: Limiter (Safety Module); Autopilot (Flight Controller).
Implementation requirements:
Consume data from Communication Module with UAS.
Produce navigation state (e.g. position, velocity, attitude, time).
Publish to both Limiter and Autopilot with defined update rate and format.
2.3 Safety Module (Модуль безопасности)
The Safety Module is a subsystem. All of its components share the responsibility of ensuring safe operation and enforcing limits before commands reach actuators.
2.3.1 Mission (Control) — Миссия (контроль)
Attribute
Value
Role
Mission parameters and control from a safety/oversight perspective.
Inputs
Control and mission-related data from Communication Module with ATM.
Outputs
(Implicit: used by other safety components; specify in implementation.)
2.3.2 Event Log (Журнал событий)
Attribute
Value
Role
Records significant safety-related events and actions.
Inputs
Event data from Limiter; event data from Safety Monitor.
Outputs
Log storage / retrieval API (no direct diagram outputs).
Navigation data from Navigation System; data/commands (dashed) from Communication Module with UAS.
Outputs
Control signals to Limiter; commands to Release Control; commands to Motor Drives Control.
Implementation requirements:
Do not send commands directly to Actuators; all actuator-bound commands go via Limiter.
Outputs: (1) to Limiter (for actuator path), (2) to Release Control, (3) to Motor Drives Control.
2.4.2 Mission (Operator) — Миссия (оператор)
Attribute
Value
Role
Operator mission commands or status (monitoring / command injection).
Inputs
Data/commands (dashed) from Communication Module with UAS.
Outputs
(To Autopilot or internal FC logic; specify in implementation.)
2.4.3 Release Control (Управление сбросом)
Attribute
Value
Role
Manages payload release or deployment.
Inputs
Commands from Autopilot.
Outputs
(To physical release mechanism; may go via Limiter/Actuators depending on design.)
2.4.4 Motor Drives Control (Управление приводами моторов)
Attribute
Value
Role
Motor speed and direction.
Inputs
Commands from Autopilot.
Outputs
(To physical motors; diagram implies these are ultimately gated by Limiter → Actuators.)
Implementation note: The diagram shows Actuators receiving only from Limiter and Emergency Systems Control. Therefore Motor Drives Control and Release Control must feed into the path that goes through the Limiter (and then to Actuators), or be modeled as logical sub-actuators that receive from Limiter.
2.5 Actuators (Приводы)
Attribute
Value
Role
Physical execution of commands (motors, control surfaces, release mechanisms).
Inputs
Only from Limiter (normal path) and Emergency Systems Control (emergency path).
Outputs
Physical action.
Implementation requirements:
Actuators must have exactly two command sources: Limiter and Emergency Systems Control.
Define priority/arbitration if both can command at once (e.g. emergency overrides normal).
Autopilot → Limiter, Release Control, Motor Drives Control
No direct Autopilot → Actuators.
Safety-critical path
Nav + Autopilot + Emergency state → Limiter → Event Log, Actuators
All normal actuator commands via Limiter.
Emergency path
Broker (IPC) ↔ Emergency Systems Control → Limiter, Actuators
Emergency logic can command actuators.
Logging
Safety Monitor, Limiter → Event Log
Safety events recorded.
4. Constraints and Rules
Single gate to actuators: All normal commands to Actuators go through the Limiter. Emergency Systems Control may send commands directly to Actuators.
No bypass: Autopilot must not connect directly to Actuators; only to Limiter, Release Control, and Motor Drives Control.
Safety overlay: The Safety Module (Limiter + Emergency Systems Control + Safety Monitor + Event Log + Broker) is the safety overlay; it must be able to restrict or override unsafe commands.
Real-time and reliability: Limiter and Emergency Systems Control are safety-critical; specify timing and reliability (e.g. deadlines, redundancy) in the implementation.
Modularity: Components must be replaceable or testable in isolation with defined inputs/outputs and interfaces.
5. Implementation Hints
Protocols: Use project broker (Kafka/MQTT) for IPC (Broker (IPC)); define separate channels/topics per producer-consumer pair where needed.
Message format: Align with existing project convention (e.g. action, payload, sender, correlation_id, reply_to) for compatibility.
Failure modes: Specify behavior when Navigation, Autopilot, or Communication Module fail (e.g. Limiter defaults to safe hold, Emergency Systems Control takes over).
Testing: Provide simulators or mocks for DTE, Navigation System, and Autopilot so that Safety Module and Flight Controller can be tested without hardware.