Inertial navigation system architecture generation method, apparatus and device, and medium
By using component derivation and interface connections in a graphical modeling environment, multiple versions of the inertial navigation system architecture are automatically generated, solving the problems of low efficiency and error-proneness in traditional design. This enables efficient and accurate inertial navigation system architecture design, adapting to diverse needs.
Patent Information
- Application Number
- CN202511249348.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-03
- Publication Date
- 2025-12-19
AI Technical Summary
Traditional inertial navigation system architecture design relies on engineers' experience, resulting in low design efficiency, difficulty in quickly responding to diverse and complex performance requirements, and the error-prone nature of manual design, making it difficult to generate high-precision, low-power, and interference-resistant inertial navigation system architectures.
In a graphical modeling environment, multiple versions of candidate internal block diagram architectures are automatically generated through component derivation and interface connection. A high-quality reference internal block diagram architecture is output through a filtering module, improving design efficiency and accuracy.
It has improved the efficiency and accuracy of inertial navigation system architecture design, enabling it to quickly adapt to the dynamic characteristics and environmental interference of different carriers, and improving reusability and multi-scenario adaptability of the design.
Smart Images

Figure CN121167809A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of inertial navigation system design technology, and in particular to a method, apparatus, device and medium for generating the architecture of an inertial navigation system. Background Technology
[0002] With the widespread application of navigation technology in aerospace, autonomous driving, and military equipment, the performance requirements of Inertial Navigation Systems (INS) are becoming increasingly diverse and complex. In aerospace, ship navigation, and land transportation, INS, as a core navigation device, is crucial for ensuring autonomous, continuous, and accurate positioning of the vehicle. As application scenarios expand and performance requirements upgrade, the architecture of INS is becoming increasingly complex, needing to adapt to the dynamic characteristics of different vehicles, the intensity of environmental interference, and hardware resource constraints.
[0003] Traditional design patterns based on documents and experience rely heavily on engineers' experience for inertial navigation system architecture design, employing a trial-and-error approach for iteration. This approach is inefficient, and when faced with multi-dimensional requirements such as high precision, low power consumption, and anti-interference, manually building the architecture takes a long time and is difficult to respond quickly to market changes. Summary of the Invention
[0004] This invention provides a method, apparatus, device, and medium for generating the architecture of an inertial navigation system, so as to improve the efficiency of generating the architecture of an inertial navigation system.
[0005] According to one aspect of the present invention, a method for generating the architecture of an inertial navigation system is provided, comprising:
[0006] An initial block definition diagram is constructed based on the basic components of the inertial navigation system configured by the user in the graphical modeling environment;
[0007] The components and interfaces of the initial block definition graph are derived to obtain at least two candidate internal block graph architectures of the inertial navigation system;
[0008] The reference internal block diagram architecture of the inertial navigation system is selected from the at least two candidate internal block diagram architectures.
[0009] According to another aspect of the present invention, an inertial navigation system architecture generation apparatus is provided, comprising:
[0010] The building module is used to construct an initial block definition diagram based on the basic components of the inertial navigation system configured by the user in the graphical modeling environment;
[0011] A derivation module is used to derive the components and interfaces of the initial block definition graph to obtain at least two candidate internal block graph architectures of the inertial navigation system.
[0012] A filtering module is used to filter the reference internal block diagram architecture of the inertial navigation system from the at least two candidate internal block diagram architectures.
[0013] According to another aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the architecture generation method for an inertial navigation system according to any embodiment of the present invention.
[0014] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute the architecture generation method of the inertial navigation system according to any embodiment of the present invention.
[0015] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the architecture generation method of the inertial navigation system according to any embodiment of the present invention.
[0016] This invention transforms the derivation logic of inertial navigation system components (such as low-cost derivation based on MEMS gyroscopes and high-precision derivation based on fiber optic gyroscopes) into executable rules in a graphical modeling environment, automatically generating multiple versions of derived components and connecting them via interfaces. The user's main task shifts from component design to comparative analysis of existing architectures, solving the problems of error-prone and inefficient manual derivation, and significantly improving the efficiency and accuracy of architecture design.
[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description
[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0019] Figure 1 This is a flowchart of an inertial navigation system architecture generation method according to an embodiment of the present invention;
[0020] Figure 2AThis is a flowchart of an inertial navigation system architecture generation method according to another embodiment of the present invention;
[0021] Figure 2B This is a schematic diagram of an architecture generation process provided according to another embodiment of the present invention;
[0022] Figure 3 This is a schematic diagram of the architecture generation device for an inertial navigation system according to another embodiment of the present invention;
[0023] Figure 4 This is a schematic diagram of the structure of an electronic device that implements an embodiment of the present invention. Detailed Implementation
[0024] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0025] It should be noted that the terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0026] Before introducing the embodiments of the present invention, the relevant technologies of the present invention will be briefly described. Traditional design patterns based on documents and experience inevitably have the following problems:
[0027] Low architecture generation efficiency: Manually deriving the inertial navigation system architecture requires repeatedly sorting out component interfaces and functional logic. In the face of scenarios with multiple component derivations and multiple interface combinations, it is time-consuming and laborious, and it is difficult to quickly respond to diverse needs.
[0028] Insufficient design completeness: Manual design is prone to overlooking potential architectural combinations and cannot fully cover all possibilities of "component derivation-interface connection", resulting in the neglect of high-quality architectural solutions.
[0029] Model consistency is difficult to guarantee: the requirements, design and implementation phases rely on documents to convey information, and component derivation rules and interface connection logic can easily lead to semantic gaps between requirements, models and implementations, causing contradictions in later integration.
[0030] Poor adaptability to multiple scenarios: Different application scenarios (such as high-dynamic aircraft and low-power vehicle) have different requirements for inertial navigation architecture. Traditional methods are difficult to generate targeted architectures efficiently and have low reusability.
[0031] Model-Based Systems Engineering (MBSE), using SysML as its core language, defines system components and interfaces through Block Definition Diagrams (BDDs) and describes component interactions through Internal Block Diagrams (IBDs), providing a model-driven approach for inertial navigation system (INS) architecture design. However, current MBSE practices lack automated architecture generation methods for scenarios involving the derivation characteristics of INS components and full / maximum interface connectivity. There is an urgent need to overcome the "BDD-IBD" conversion bottleneck and achieve efficient and accurate generation of massive architectures. While MBSE technology enables end-to-end tracking from requirements to design by constructing formal system models, existing MBSE-based INS design is often limited to static modeling of single architectures, lacking the ability to automatically generate and optimize massive candidate architectures. Therefore, a method that integrates the advantages of MBSE modeling is urgently needed to achieve rapid generation, multi-objective optimization, and adaptive adjustment of INS architectures.
[0032] Figure 1 This is a flowchart illustrating an inertial navigation system architecture generation method according to an embodiment of the present invention. This embodiment is applicable to situations where, after a user designs the basic components of an inertial navigation system architecture, the system derives from these basic components and generates corresponding reference internal block diagram architectures for user analysis and selection. This method can be executed by an inertial navigation system architecture generation device, which can be implemented in hardware and / or software. This device can be configured in an electronic device with corresponding data processing capabilities, such as an architecture design system. Figure 1 As shown, the method includes:
[0033] S110. Construct an initial block definition diagram based on the basic components of the inertial navigation system configured by the user in the graphical modeling environment.
[0034] S120. Derive the components and interfaces of the initial block definition graph to obtain at least two candidate internal block graph architectures of the inertial navigation system.
[0035] S130. Select a reference internal block diagram architecture for the inertial navigation system from the at least two candidate internal block diagram architectures.
[0036] Specifically, in the graphical modeling (SysML) environment, users manually define the basic components of the inertial navigation system (such as inertial measurement units, signal processing modules, navigation calculation modules, etc.) and their interfaces, specifying the component attributes and interface types (input / output / bidirectional interfaces). Based on this information, the system constructs an initial internal block diagram, which serves as the meta-model for subsequent architecture generation.
[0037] The basic components in the initial internal block diagram are extended by derivation to generate derived components and their interfaces that are not defined by the user, thereby enriching the component pool of the architecture design, while preserving the interface compatibility and inheritance relationship between the derived components and the original components. The interfaces of the derived components and the basic components are connected in different ways to obtain a large number of candidate internal block diagram architectures.
[0038] The candidate internal block diagram architectures are filtered, and one or more that meet the user's needs are selected as reference internal block diagram architectures and output to the user. The user can then further analyze and select from the reference internal block diagram architectures.
[0039] This invention transforms the derivation logic of inertial navigation system components (such as low-cost derivation based on MEMS gyroscopes and high-precision derivation based on fiber optic gyroscopes) into executable rules in a graphical modeling environment, automatically generating multiple versions of derived components and connecting them via interfaces. The user's main task shifts from component design to comparative analysis of existing architectures, solving the problems of error-prone and inefficient manual derivation, and significantly improving the efficiency and accuracy of architecture design.
[0040] Figure 2A This is a flowchart illustrating a method for generating the architecture of an inertial navigation system according to another embodiment of the present invention. This embodiment is an optimization and improvement upon the above embodiment. Figure 2A As shown, the method includes:
[0041] S210. Construct an initial block definition diagram based on the basic components of the inertial navigation system configured by the user in the graphical modeling environment.
[0042] S220. Based on user-defined derivation rules, derive derived components and their interfaces from the basic components in the initial block definition graph.
[0043] S230. Connect the interfaces of the basic components and derived components to obtain at least two candidate internal block diagram architectures.
[0044] Among them, derived components include components derived from basic components and components derived from the interfaces of basic components.
[0045] Specifically, based on user-defined derivation rules, the basic component is extended to generate multi-form derived components. The interfaces of the derived components are also extended, and their data types, transmission protocols, and other attributes are specified. The interfaces of the basic and derived components are then connected. Due to the diverse interface connection methods, a large number of candidate internal block diagram architectures are generated.
[0046] Based on the above embodiments, optionally, connecting the interfaces of the basic component and the derived component to obtain at least two candidate internal block diagram architectures includes:
[0047] Based on the basic interface connection rules, all interfaces are traversed to generate a full set of interface connection schemes containing all possible interface connection relationships;
[0048] The interfaces of the basic components and derived components are connected according to the full interface connection scheme to obtain at least two candidate internal block diagram architectures.
[0049] Specifically, such as Figure 2B As shown, there are two generation modes for the candidate internal block diagram architecture: one is the maximum number of connections generation mode (ALL). In this mode, after determining the interfaces that cannot be connected to each other according to the basic interface connection rules, the system traverses all legal interfaces of the derived components to generate a full set of interface connection schemes containing all possible interface connection relationships. The full set of interface connection schemes is then executed to generate a set of candidate internal block diagram architectures containing all possible interface connection relationships.
[0050] Based on the above embodiments, optionally, connecting the interfaces of the basic component and the derived component to obtain at least two candidate internal block diagram architectures includes:
[0051] Based on the basic interface connection rules and the extended interface connection rules selected by the user, and with the goal of maximizing the number of effective interface connections, the optimal interface connection scheme that satisfies the rule constraints is searched.
[0052] The interfaces of the basic components and derived components are connected according to the optimal interface connection scheme to obtain at least two candidate internal block diagram architectures.
[0053] For details, please refer to [link / reference]. Figure 2BAnother mode is the maximum connection count generation mode (O(n)select). In this mode, in addition to the default basic interface connection rules, there are also user-selected extended interface connection rules. In the extended interface connection rules, the user defines specific connection logic, such as that component A and component B must have at least one pair of interfaces connected to each other, and that interfaces of type A and type B in the system are preferentially connected. Under the constraints of the extended interface connection rules, with the goal of "maximizing the number of effective interface connections," a graph theory algorithm (such as the maximum matching algorithm) is used to search for the optimal interface connection scheme that satisfies the constraints, thus obtaining the optimal interface connection scheme. Executing the optimal interface connection scheme generates the maximum connection count IBD architecture, suitable for scenarios that prioritize functional integration and high interface utilization. In short, the full generation mode ensures that no legal interface connection combination is missed, while the maximum connection count mode can discover highly integrated architectures, comprehensively covering potential high-quality solutions and avoiding the limitations of manual design. Users can choose between the two modes as needed.
[0054] Based on the above embodiments, optionally, the basic interface connection rules include compatibility matching and functional logic adaptation between the two interfaces.
[0055] Specifically, two interfaces that can be connected to each other must at least be compatible (such as electrical characteristics and data rate matching) and functional logic compatible (such as the measurement data interface needing to be connected to the solution module interface) to avoid generating an invalid connection architecture.
[0056] In the above embodiments, optionally, the derivation rules include functional enhancement derivation, lightweight derivation, and redundant design derivation.
[0057] Specifically, functional enhancement derivation refers to improving the value and competitiveness of inertial navigation system (INS) products by adding new functions or improving existing functions, based on the functions already implemented in the basic components. Lightweight derivation refers to reducing the weight of INS products by optimizing structural design or improving manufacturing processes while keeping the functions of the basic components unchanged. Redundant design derivation focuses on improving the reliability and fault tolerance of INS products by adding additional components or systems. Its core objective is to achieve higher stability and reliability by increasing system complexity. By adjusting component derivation rules (such as switching between high-precision / low-cost derivation) and selecting generation modes (full / maximum interconnection), different scenarios such as high-dynamic aviation and low-power automotive applications can be quickly adapted, improving architecture reusability by more than 50%.
[0058] S240. The candidate internal block graph architecture that meets the user-defined filtering conditions among the at least two candidate internal block graph architectures is determined as the reference internal block graph architecture of the inertial navigation system.
[0059] Specifically, candidate internal block diagram architectures are filtered based on user-defined screening criteria (e.g., functional coverage of no less than 80%, hardware resource consumption of less than 100G, and interface conflict rate of no more than 10%). Architectures that do not meet the screening criteria (i.e., invalid / redundant architectures) are filtered out, and the remaining candidate internal block diagram architectures are the reference internal block diagram architectures.
[0060] Based on explicit screening criteria, this invention automatically filters massive architectures and outputs a high-quality set of reference internal block diagram architectures, helping designers focus on core solutions and reducing decision-making costs.
[0061] Figure 3 This is a schematic diagram of the architecture generation device for an inertial navigation system provided in another embodiment of the present invention. Figure 3 As shown, the device includes:
[0062] Module 310 is used to construct an initial block definition diagram based on the basic components of the inertial navigation system configured by the user in the graphical modeling environment;
[0063] The derivation module 320 is used to derive the components and interfaces of the initial block definition graph to obtain at least two candidate internal block graph architectures of the inertial navigation system.
[0064] The filtering module 330 is used to filter the reference internal block diagram architecture of the inertial navigation system from the at least two candidate internal block diagram architectures.
[0065] The inertial navigation system architecture generation apparatus provided in this embodiment of the invention can execute the inertial navigation system architecture generation method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.
[0066] Optional, derived modules include:
[0067] A derivation unit is used to derive derived components and interfaces of the derived components from the basic components in the initial block definition graph based on user-defined derivation rules.
[0068] A connection unit is used to connect the interfaces of the basic component and the derived component to obtain at least two candidate internal block diagram architectures.
[0069] Optionally, the connection unit is specifically used to: search for the optimal interface connection scheme that satisfies the rule constraints based on the basic interface connection rules and the extended interface connection rules selected by the user, with the maximization of the number of effective interface connections as a reference; and connect the interfaces of the basic component and the derived component according to the optimal interface connection scheme to obtain at least two candidate internal block diagram architectures.
[0070] Optionally, the connection unit is specifically used to: traverse all interfaces based on the basic interface connection rules to generate a full interface connection scheme containing all possible interface connection relationships; and connect the interfaces of the basic component and the derived component according to the full interface connection scheme to obtain at least two candidate internal block diagram architectures.
[0071] Optionally, the basic interface connection rules include compatibility matching and functional logic adaptation between the two interfaces.
[0072] Optionally, the derivation rules include functional enhancement derivation, lightweight derivation, and redundant design derivation.
[0073] Optionally, the filtering module 330 is specifically used to: determine the candidate internal block graph architecture that meets the user-defined filtering conditions from the at least two candidate internal block graph architectures as the reference internal block graph architecture of the inertial navigation system.
[0074] The inertial navigation system architecture generation apparatus described in further detail can also execute the inertial navigation system architecture generation method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.
[0075] Figure 4 A schematic diagram of an electronic device 40 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.
[0076] like Figure 4 As shown, the electronic device 40 includes at least one processor 41 and a memory, such as a read-only memory (ROM) 42 or a random access memory (RAM) 43, communicatively connected to the at least one processor 41. The memory stores computer programs executable by the at least one processor. The processor 41 can perform various appropriate actions and processes based on the computer program stored in the ROM 42 or loaded into the RAM 43 from storage unit 48. The RAM 43 may also store various programs and data required for the operation of the electronic device 40. The processor 41, ROM 42, and RAM 43 are interconnected via a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.
[0077] Multiple components in electronic device 40 are connected to I / O interface 45, including: input unit 46, such as keyboard, mouse, etc.; output unit 47, such as various types of monitors, speakers, etc.; storage unit 48, such as disk, optical disk, etc.; and communication unit 49, such as network card, modem, wireless transceiver, etc. Communication unit 49 allows electronic device 40 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0078] Processor 41 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 41 performs the various methods and processes described above, such as the architecture generation method for inertial navigation systems.
[0079] In some embodiments, the inertial navigation system architecture generation method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 48. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 40 via ROM 42 and / or communication unit 49. When the computer program is loaded into RAM 43 and executed by processor 41, one or more steps of the inertial navigation system architecture generation method described above may be performed. Alternatively, in other embodiments, processor 41 may be configured to perform the inertial navigation system architecture generation method by any other suitable means (e.g., by means of firmware).
[0080] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0081] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0082] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0083] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0084] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.
[0085] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.
[0086] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.
[0087] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.
Claims
1. A method for generating the architecture of an inertial navigation system, characterized in that, The method includes: An initial block definition diagram is constructed based on the basic components of the inertial navigation system configured by the user in the graphical modeling environment; The components and interfaces of the initial block definition graph are derived to obtain at least two candidate internal block graph architectures of the inertial navigation system; The reference internal block diagram architecture of the inertial navigation system is selected from the at least two candidate internal block diagram architectures.
2. The method according to claim 1, characterized in that, The process of deriving components and interfaces from the initial block definition graph to obtain at least two candidate internal block graph architectures for the inertial navigation system includes: Based on user-defined derivation rules, derived components and interfaces of the derived components are obtained by deriving from the basic components in the initial block definition graph. The interfaces of the basic components and derived components are connected to obtain at least two candidate internal block diagram architectures.
3. The method according to claim 2, characterized in that, The process of connecting the interfaces of the basic components and derived components to obtain at least two candidate internal block diagram architectures includes: Based on the basic interface connection rules and the extended interface connection rules selected by the user, and with the goal of maximizing the number of effective interface connections, the optimal interface connection scheme that satisfies the rule constraints is searched. The interfaces of the basic components and derived components are connected according to the optimal interface connection scheme to obtain at least two candidate internal block diagram architectures.
4. The method according to claim 2, characterized in that, The process of connecting the interfaces of the basic components and derived components to obtain at least two candidate internal block diagram architectures includes: Based on the basic interface connection rules, all interfaces are traversed to generate a full set of interface connection schemes containing all possible interface connection relationships; The interfaces of the basic components and derived components are connected according to the full interface connection scheme to obtain at least two candidate internal block diagram architectures.
5. The method according to claim 3 or 4, characterized in that, The basic interface connection rules include compatibility matching and functional logic adaptation between the two interfaces.
6. The method according to claim 2, characterized in that, The derivation rules include functional enhancement derivation, lightweight derivation, and redundant design derivation.
7. The method according to claim 1, characterized in that, The step of selecting a reference internal block graph architecture for the inertial navigation system from the at least two candidate internal block graph architectures includes: The candidate internal block graph architecture that meets the user-defined filtering conditions among the at least two candidate internal block graph architectures is determined as the reference internal block graph architecture of the inertial navigation system.
8. An inertial navigation system architecture generation device, characterized in that, The device includes: The building module is used to construct an initial block definition diagram based on the basic components of the inertial navigation system configured by the user in the graphical modeling environment; A derivation module is used to derive the components and interfaces of the initial block definition graph to obtain at least two candidate internal block graph architectures of the inertial navigation system. A filtering module is used to filter the reference internal block diagram architecture of the inertial navigation system from the at least two candidate internal block diagram architectures.
9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the architecture generation method for the inertial navigation system according to any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the architecture generation method for the inertial navigation system according to any one of claims 1-7.