# Avionics > Airborne software, with every controlled item approved by name. Source: https://neuralinverse.com/industries/avionics/ --- ![](/photos/hangar.jpg) [Industries / Aerospace and defence](https://neuralinverse.com/industries/) # Airborne software, with every controlled item approved by name. For software and airborne electronic hardware teams under DO-178C and DO-254. Your qualified tools and plans stay as they are. Standards DO-178C · DO-254 · DO-330 Firmware tools Arm GCC, Arm Compiler 6, IAR, J-Link, ST-LINK FPGA tools Verilator, GHDL, Yosys; Vivado, Quartus, Libero, Radiant Agent policy Avionics sector template Deployment Self-hosted, your cloud or air-gapped What your team gets ## Built around your plans, not around the AI. Govern features are in use today. Domain modules are pre-release; their state is listed under Tools and formats. - **Controlled items stay controlled:** The avionics template makes agent changes to requirements and trace data wait for a named approver, and denies agent changes to qualified-tool configuration and released baselines. - **Firmware in the Editor:** Build, unit-test, flash and debug microcontroller firmware with your compilers and probes, with registers from the SVD and RTOS awareness. - **FPGA designs for DO-254:** Lint, simulation, formal verification and timing reports beside the RTL, on the open tools or your vendor tools. - **Evidence of AI use:** Signed evidence packs say which lines AI touched, which model and context were used and who approved. Anyone can verify one offline. - **Closed networks:** Govern runs air-gapped, with models served inside your network. Who uses it ## For every role from the requirement to the certification liaison. - **Software engineers:** Build, test and debug flight software, with agents working under the avionics template. - **Airborne electronic hardware engineers:** Lint, simulate, synthesise and read timing for FPGA designs. - **Verification engineers:** Run host unit tests, testbenches and formal properties, with pass or fail per test. - **Configuration managers:** Approve changes to requirements, trace data and release branches as named approvers. - **Certification liaison:** Export the audit record and evidence packs for your assessor. Tools and formats ## What the modules handle, and how far each is verified. The Embedded and HDL modules drive the tools you already qualified. They do not replace them. - **Firmware projects:** Keil, IAR and STM32CubeIDE projects imported into CMake; builds of a CMake preset with a Flash and RAM report; host unit tests. Built and tested on recorded tool output; not yet run against IAR or Keil. - **Flash and debug:** Flashing after a confirmation; debugging with peripheral registers from the SVD, RTOS awareness, fault decoding and a serial monitor. Running an image in QEMU is verified against QEMU 9.1.1; nothing has been run on a board. - **Static analysis:** Cppcheck findings, including MISRA C:2012, in the Problems view. Built and tested on recorded tool output. - **FPGA, open flow:** Lint, simulation, cocotb testbenches, formal verification, waveforms, synthesis and place and route. Verified on Linux. Programming a board is not yet run. - **FPGA, vendor flows:** The vendor tools driven in batch mode, with their messages and timing and utilisation reports in the same views. Kit shipped or modelled: not yet run against the vendor tools. Domain modules are pre-release. Nothing is verified by a customer yet, and nothing is verified on Windows. Do not rely on a capability for production work until it is verified for your tools, versions and operating system. Product names belong to their owners. How a change moves ## A person decides before anything leaves the desk. 1. Propose An engineer or agent drafts a change to flight software or its trace data. 2. Verify Your qualified tools build, check and test it. 3. Approve A push to a release branch waits for a named approver. 4. Record Change, results and approval kept together in the audit record. Standards ## Evidence for your plans. The certification is yours. - **DO-178C:** Evidence toward DO-178C: changes to requirements, trace data and release branches with their approver and reason, in a tamper-evident record. - **DO-330:** Evidence toward DO-330: agents are denied changes to qualified-tool configuration, and every decision is logged. - **DO-254:** Evidence toward DO-254: each implementation run kept with the commit it came from, and each RTL change with its review and approval. Neural Inverse provides evidence toward these standards. Certification stays with your organisation and assessor. Products used [Neural Inverse Build → Editor, Agents and CLI with the domain tools your engineers need.](https://neuralinverse.com/build/)[Neural Inverse Govern → Policy, approvals and audit for every AI tool your teams use.](https://neuralinverse.com/govern/) Product names belong to their owners. Related industries[Defence and space](https://neuralinverse.com/industries/defence/)[Semiconductors and FPGA](https://neuralinverse.com/industries/semiconductors/)[Medical devices](https://neuralinverse.com/industries/medical/) ![](/photos/team.jpg) ## Talk to our team. Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation. [Request access](https://neuralinverse.com/contact/?topic=access)[Contact us](https://neuralinverse.com/contact/)