Products

Leading domestic R&D and manufacturer of unmanned aerial vehicle control systems and unmanned aerial vehicle solutions

products

Model support environment

Model grading

Referring to the usual hierar

Referring to the usual hierarchical approach in military modeling and simulation, the model is divided into three levels:

Task level or campaign level (L1): Focusing on system functional models that meet the requirements of equipment functionality and performance indicators for campaigns or missions. The input-output interface meets the requirements of the modeling object, and the model is established using highly simplified formulas.

Combat or Tactical Level (L2): A system functional model used to verify whether specific performance indicators of equipment meet usage requirements. On the basis of meeting L1 level requirements, the specific requirements for interfaces, processing logic, prerequisites, timing, etc. of the model are consistent with the modeling object. Generally, simplified mechanics, fluids, motion, electromagnetics formulas or equivalent formulas are used for modeling.

Engineering level (L3): A system performance model used to verify whether equipment design meets design specifications. The model meets L2 level requirements. Modeling needs to be based on the actual structure, working principle, environmental conditions and other constraints of the modeling object, combined with more accurate mechanics, fluid, motion, electromagnetics formulas or equivalent formulas for modeling.

Existing models

The existing models provided cover commonly used fixed wing aircraft, rotary wing aircraft, special aircraft, and space vehicles in the aerospace field, as well as their onboard and load equipment, including flight control, avionics, electromechanical, hydraulic and other system equipment, as well as equipment models such as radar, sensors, guidance, and guidance algorithms.


Model support environment

Model Design Concept - Modular Design

All models follow the modular design concept: the model design implements module division based on the actual system composition relationship, with clear structure and function of each module, making it easy to understand and use.

Model support environment

The input and output of the model adopt a unified interface, which facilitates the combination of multiple models.Model support environment

Model Design Concept - Unified Internal Interface Standards

 Modeling Specification Requirements

 modeling interface standard

 motion model input and output standards

 route format standard

Model design concept - supported by multiple simulation methods

All simulation models support real-time simulation and ultra real-time simulation. It supports both semi physical simulation experiments and fully digital deduction simulations. Some models support variable step size settings to provide higher speed ultra real-time simulation.

For example, corresponding to an immutable step size model, in a state where ultra real-time simulation can support 5-fold acceleration calculation, and certain conditions are met to support variable step size, by adjusting the step size to the original 5-fold, it can provide the ability to accelerate calculation by 25 times.

Model design concept - supports multiple model usage methods

supports multiple operating systems

supports dynamic library DLL loading and calling in Windows environments

supports loading and calling dynamic libraries so in Linux environments

supports loading and calling dynamic library a in vxworks environment

supports loading and calling dynamic libraries in the labview environment

supports the release of FMU2.0 version

supports code generation for use in C/C++code

Model design concept - online parameter tuning

Online parameter tuning refers to a method of adjusting model operating parameters through external inputs during model operation, which affects the calculation results and output of the model. According to the Modeling Interface Standard, each model has two parameter adjustment methods: configuration parameters and input parameters.

The u configuration parameter is a parameter designed in the model that participates in model calculation and is loaded once during model initialization. The model provides a configuration parameter setting interface according to the Modeling Interface Standard, which can be adjusted before the model runs.

The input parameter u is the amount of change calculated in each cycle of the model. The model provides an input parameter setting interface according to the Modeling Interface Standard, which can be adjusted before each cycle calculation of the model.

Model Design Concept - Fault Injection

Fault injection is the simulation of faults in the simulated object by a model. The model provides a fault input interface based on the possible fault characteristics of the modeling object, and simulates the fault response in the model. Common faults include:

U state coverage, including normal state, error state, fault state, on/off state, and other state values coverage

U logical value bias, including fixed value, relative constant value, noise value, function value, and other forms

U ICD format, according to the definition of ICD, changes are made to specific data such as frame headers, flag bits, verification bits, etc

Heterogeneous distributed simulation computing

The model runtime platform is a heterogeneous distributed simulation computing platform that can flexibly configure runtime wake-up according to different operating scenario requirements, achieving functions such as full digital simulation, semi physical simulation, and virtual real combined simulation verification.

Model support environment



Model support environment          Model support environment

supports multiple types of computers, including workstations, servers, CPCI, PXI chassis, etc.

supports multiple architecture processors, including X86, ARM, Loongson, and other processor architectures.

supports multiple operating systems, including Windows series, Linux, VxWorks, Labview, Kirin, and Tongxin.

supports multiple data network structures, including reflective memory networks, high-speed Ethernet, and more.

supports multiple clock synchronization methods, such as external clock, NTP, IEEE1588, etc.

supports up to 64 nodes for synchronous computing, with real-time access and dynamic load balancing capabilities.

supports ultra real-time simulation under limited conditions, allowing multiple simulation tasks to be executed simultaneously under limited conditions.

supports model extension kernel and time sharing scheduling that meets interface standards, is compatible with FMU2.0 interface protocol, and supports direct compilation of C/C++code.

supports real-time monitoring of the access status, operation status, and model scheduling status of simulation nodes.

supports a simulation scheduling cycle of less than 1ms, with a scheduling delay of less than 10us (delays may vary in different operating system environments).

supports various physical interface forms to interact with actual systems, including serial port, 4291553B, AFDX, FC, digital quantity, analog quantity, rotary transformer, etc.

Experimental network

The experimental network consists of a real-time data network, a universal control network, a clock synchronization network, and network interfaces.

Universal control network: implemented based on high-speed Ethernet, it completes instruction communication between various test equipment and subsystems, including instruction issuance, instruction feedback, and non real-time data transmission. The simulation status of each test subsystem is also fed back to the test management system through the universal control network.

data network: implemented based on reflective memory network or low latency high-speed Ethernet, the system is configured with reflective memory network to achieve data communication between nodes. In the reflective memory network, when data is written to the local reflective memory, it is simultaneously transmitted to other connected computers without software delay and with minimal hardware delay. The implementation function of low latency high-speed Ethernet is the same as that of reflective memory network. The data network can be compatible with clock synchronization network functions as needed.

UClock synchronization network: The clock synchronization network is used to synchronize the clocks of various systems/devices in the experimental environment, ensuring that each system calculates at the same clock cycle, and that the generated and saved data has the same clock mark The timing interface and protocol option IEEE1588 and NTP

The typical real-time data network structure is as follows



Model support environment

Intelligence Redefines Flight

Contact Us