CN117908845A - Software architecture design method capable of meeting multi-node data distribution - Google Patents
Software architecture design method capable of meeting multi-node data distribution Download PDFInfo
- Publication number
- CN117908845A CN117908845A CN202311834125.XA CN202311834125A CN117908845A CN 117908845 A CN117908845 A CN 117908845A CN 202311834125 A CN202311834125 A CN 202311834125A CN 117908845 A CN117908845 A CN 117908845A
- Authority
- CN
- China
- Prior art keywords
- data
- layer
- node
- hardware
- monitoring
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000013461 design Methods 0.000 title claims abstract description 27
- 238000000034 method Methods 0.000 title claims abstract description 19
- 238000012545 processing Methods 0.000 claims abstract description 37
- 238000012544 monitoring process Methods 0.000 claims abstract description 31
- 230000003993 interaction Effects 0.000 claims abstract description 16
- 230000006870 function Effects 0.000 claims description 22
- 230000005540 biological transmission Effects 0.000 claims description 10
- 231100000279 safety data Toxicity 0.000 claims description 3
- 230000008878 coupling Effects 0.000 abstract description 4
- 238000010168 coupling process Methods 0.000 abstract description 4
- 238000005859 coupling reaction Methods 0.000 abstract description 4
- 238000012360 testing method Methods 0.000 abstract description 2
- 238000007726 management method Methods 0.000 description 28
- 238000010586 diagram Methods 0.000 description 4
- 238000012423 maintenance Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 238000013523 data management Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000004132 cross linking Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000003786 synthesis reaction Methods 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The application belongs to the field of airborne software design, and particularly relates to a software architecture design method capable of meeting multi-node data distribution. The method comprises the following steps: step S1, dividing a multi-node data distribution system into a software architecture comprising a hardware management layer, a platform system layer and an application processing layer, and carrying out data interaction among all the layers through interfaces; s2, configuring a hardware management layer to perform data interaction with each onboard network bus through driving; step S3, configuring a platform system layer to perform task scheduling, memory management and time management, and performing data interaction with a hardware management layer; and S4, configuring an application processing layer to analyze data of a platform system layer or send a data group packet to the platform system layer, monitoring each network bus connected with the hardware physical layer, and generating the data group packet to be sent based on a monitoring result. The application reduces the design safety difficulty caused by strong coupling of the system and improves the software realization and test efficiency.
Description
Technical Field
The application belongs to the field of airborne software design, and particularly relates to a software architecture design method capable of meeting multi-node data distribution.
Background
At present, the advanced aviation aircraft system architecture has the characteristics of decoupling, sustainable system expansion, interface universalization, distribution and the like. Aiming at the characteristics, in order to solve the problems of data interaction, unified management of whole system data, state monitoring and the like among different bus networks, a high-performance and high-safety software architecture capable of meeting different hardware architectures is needed to support the development of functions.
In future aircraft designs, centralized system designs are mostly adopted, the hardware devices are greatly reduced by the centralized system, and more system functions are realized by software. However, the centralized system design reduces the weight of the aircraft, increases the coupling of the system, increases the difficulty of software function design and reduces the reliability of the system. To meet this design requirement, a reliable and secure design is required for subsystem interactions, i.e., data management between subsystems.
Disclosure of Invention
In order to solve the problems, the application provides a software architecture design method for satisfying multi-node data distribution, and the functions of data management, ICD management, fault processing and the like under a plurality of bus networks are realized by reliably reconstructing various hardware buses and interface protocols.
The application provides a software architecture design method for satisfying multi-node data distribution, which mainly comprises the following steps:
Step S1, dividing a multi-node data distribution system into a software architecture comprising a hardware management layer, a platform system layer and an application processing layer, and carrying out data interaction among all the layers through interfaces;
Step S2, configuring the hardware management layer to perform data interaction with a hardware physical layer through driving, wherein the hardware physical layer is connected with each onboard network bus to realize data transmission with a sending node and a receiving node;
Step S3, configuring the platform system layer to perform task scheduling, memory management and time management, and performing data interaction with a hardware management layer;
and S4, configuring the application processing layer to analyze the data of the platform system layer, or transmitting the data group packet to the platform system layer, monitoring each network bus connected with the hardware physical layer, and generating the data group packet to be transmitted based on a monitoring result.
Preferably, in step S4, the application processing layer is configured to periodically execute task functions, where the task functions executed in each monitoring period include:
Step S41, receiving a data packet according to a definition rule of a sending node ICD;
Step S42, according to the definition rule of the ICD, acquiring a state identifier and original data in the data packet;
step S43, judging whether the state identifier is valid, when the state identifier is valid, taking the original data as processing data, and when the state identifier is invalid, taking preset safety data as processing data;
Step S44, the processing data is packaged and sent according to the definition rule of the receiving node ICD.
Preferably, step S41 is preceded by further comprising determining whether the current period is a monitoring period according to a preset monitoring rate.
Preferably, in step S41, the port driver of the hardware management layer is invoked to sequentially receive all the packets of each transmitting node.
Preferably, step S43 further includes recording a monitoring status, and in step S44, the monitoring status and the processing data are filled in a transmission packet memory.
Preferably, in step S44, the port driver of the hardware management layer is invoked to send the data of the packet to the receiving node.
According to the application, different functions are distributed into different architecture layers through layering design, so that the realization, verification and fault positioning are convenient; the method meets the adaptation requirements of different bus operation mechanisms and ICD diversity under the hardware design of a strong coupling system, can realize the safe and effective transmission of data among multiple systems, and is added with a fault monitoring mechanism to safely isolate and process distributed data.
The application reduces the design safety difficulty brought by strong coupling of the system, defines the design architecture level, is convenient for system troubleshooting and fault positioning, improves the software realization and test efficiency, and reduces the cost of future product maintenance.
Drawings
FIG. 1 is a block diagram of a preferred embodiment of a software architecture design method for satisfying multi-node data distribution.
FIG. 2 is a schematic diagram of a multi-node data distribution system architecture according to the present application.
FIG. 3 is a diagram of the deployment of the various levels of functionality of the present application.
FIG. 4 is a state of operation switching diagram of the present application;
Fig. 5 is a flow chart of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application become more apparent, the technical solutions in the embodiments of the present application will be described in more detail with reference to the accompanying drawings in the embodiments of the present application. In the drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The described embodiments are some, but not all, embodiments of the application. The embodiments described below by referring to the drawings are exemplary and intended to illustrate the present application and should not be construed as limiting the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present application without making any inventive effort, are intended to fall within the scope of the present application. Embodiments of the present application will be described in detail below with reference to the accompanying drawings.
The application provides a software architecture design method for satisfying multi-node data distribution, which mainly comprises the following steps:
Step S1, dividing a multi-node data distribution system into a software architecture comprising a hardware management layer, a platform system layer and an application processing layer, and carrying out data interaction among all the layers through interfaces;
Step S2, configuring the hardware management layer to perform data interaction with a hardware physical layer through driving, wherein the hardware physical layer is connected with each onboard network bus to realize data transmission with a sending node and a receiving node;
Step S3, configuring the platform system layer to perform task scheduling, memory management and time management, and performing data interaction with a hardware management layer;
And S4, configuring the application processing layer to analyze the data of the platform system layer, or transmitting the data group packet to the platform system layer, monitoring each network bus connected with the hardware physical layer, and generating the data group packet to be transmitted based on a monitoring result. In the distributed or centralized system architecture, the functions of unified data distribution, transmission, management and the like among multiple nodes are realized, and the communication problem among the nodes of different physical architectures is solved.
Through the steps, the architecture designed by the application is flexibly connected with different physical architectures, the feasibility of data transmission among nodes is ensured, the structure adopts layering design, interfaces among layers are connected by adopting standard interfaces, the layering function is clear, the synchronous development and layering verification of different functional modules of software and hardware are convenient, the design efficiency is greatly improved, and the maintenance cost is reduced.
Referring first to FIG. 1, a multi-node data distribution system is cross-linked to an external system. The multi-node data distribution system is used as an interaction node of each network bus hardware, is directly connected with each network bus in a hardware physical layer, and functionally distributes data from a data sending node to a data receiving node. In the data distribution process, the multi-node data distribution system can meet the requirements of identification, state monitoring, ICD configuration, safe processing and isolation of fault data packets, re-grouping of processed data and data packet transmission according to various buses of data receiving nodes and ICD definition. In the whole operation process, most of system functions are completed by software, so that the problems of weight, reliability, service life and the like brought by hardware equipment are avoided, the software functions are convenient to realize and verify, and the maintenance cost is low.
Based on the analysis, the application finally forms the multi-node data distribution system into three layers shown in fig. 2, and as described in step S1, the layers are kept isolated, and the interaction of data among the layers is completed through a universal interface. The system realizes the cross-linking of the bottom layer through different bus hardware, the hardware management layer loads each bus hardware driver and manages the drivers, namely, all bus network driver software required by the system is contained and is used for directly operating the bus hardware modules; the platform system layer is loaded with an embedded operating system kernel for managing task scheduling, memory management, time management and the like of the whole embedded system, acquires bottom layer bus data through driving, encapsulates the bottom layer bus data into a universal interface and transmits the universal interface to a task of an application layer of a higher layer, namely, driving software is subjected to system encapsulation, a standard interface is provided for the application layer, and the application software is decoupled from the bottom layer, so that the rapid transplanting of the software is realized, and the development cost of the system is reduced; tasks in the application processing layer sequentially run every cycle according to the processing sequence of the kernel of the operating system, bus data are obtained through the calling interface, the data are processed, and finally the calling interface distributes the data to a bus network of other systems.
Referring to fig. 3, for deployment of functions under various layers, a hardware management layer mainly includes drive management, register management, and the like; the platform system layer is an operating system core processing layer, adopts an embedded operating system and mainly comprises task scheduling management, time management, memory management, ICD configuration table management and the like; the application processing layer is used for periodically running various task functions according to the time plan of the embedded system, including receiving and analyzing bus data packets, monitoring the bus state, processing data according to the monitoring result, and distributing the processed data packets to other nodes on the bus.
Through hierarchical division, each function is isolated in different layers, communication can only be realized among the layers through standard interfaces, on one hand, the function fault of each layer is ensured not to spread to influence other layers, and on the other hand, the function expansion of each layer is facilitated through universal interfaces among the layers and the other layers are not influenced. The design can also effectively reduce the design and verification difficulty and reduce the maintenance cost.
In some alternative embodiments, in step S4, the application processing layer is configured to periodically perform task functions, where the task functions performed in each monitoring period include:
Step S41, receiving a data packet according to a definition rule of a sending node ICD;
Step S42, according to the definition rule of the ICD, acquiring a state identifier and original data in the data packet;
step S43, judging whether the state identifier is valid, when the state identifier is valid, taking the original data as processing data, and when the state identifier is invalid, taking preset safety data as processing data;
Step S44, the processing data is packaged and sent according to the definition rule of the receiving node ICD.
In this embodiment, according to various ICD definition rules, the corresponding interfaces can be configured quickly and efficiently, different design requirements can be met in different stages of system design, various bus networks can be adapted, data information of various bus networks can be received and processed, and processing such as monitoring, fault synthesis, alarm and the like can be implemented on part of data according to the system requirements.
As shown in fig. 4 and 5, in fig. 4, the system operation is divided into two states: and the normal running state and the fault processing state can realize state switching after the system reaches a certain condition. After the system is powered on and operated, the system firstly enters a normal operation state, and the functions of unpacking data packets, transmitting data packets and the like of the data in normal data packets are completed in the state; and when the monitored bus state is a fault, entering a fault processing state, recording the fault of the bus state in the fault processing state, carrying out safety processing on the fault bus data, adopting a safety value, and sending a safety value group packet to other system nodes. In fig. 5, the system completes certain actions every cycle due to the periodic cycle operation rule of the embedded system. In the figure, each active content is sequentially operated according to the time operation sequence in the system period, including monitoring period judgment, data receiving, bus data packet state monitoring, fault recording, data security processing, data group packet, data distribution and other activities.
In some alternative embodiments, as shown in fig. 5, step S41 is preceded by further comprising determining whether the current period is a monitoring period according to a preset monitoring rate. In this embodiment, the secure scheduling and resource management of tasks is guaranteed by the operating system of the platform system layer.
In some alternative embodiments, as shown in fig. 5, in step S41, a port driver of the hardware management layer is invoked to sequentially receive all the data packets of each sending node. In this embodiment, the APEX interface is driven through various buses to obtain bus data packets of other nodes, and information such as ID, load, check bit and the like in the bus data packets is obtained.
In some alternative embodiments, as shown in fig. 5, step S43 further includes recording a monitoring status, and in step S44, the monitoring status and the processing data are filled in a transmission packet memory. In this embodiment, according to the system requirements, checksum fault analysis is performed on the data packet to be processed, and fault alarm information is synthesized
In some alternative embodiments, as shown in fig. 5, in step S44, a port driver of the hardware management layer is invoked to send the data of the packet to the receiving node. In this embodiment, according to the system requirement, the received information or the processed information is distributed to the corresponding nodes through the bus driving APEX interface, so that node communication with different physical architectures is realized, and meanwhile, the requirement of partial data processing can be met.
The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any changes or substitutions easily contemplated by those skilled in the art within the scope of the present application should be included in the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.
Claims (6)
1. A software architecture design method for satisfying multi-node data distribution, comprising:
Step S1, dividing a multi-node data distribution system into a software architecture comprising a hardware management layer, a platform system layer and an application processing layer, and carrying out data interaction among all the layers through interfaces;
Step S2, configuring the hardware management layer to perform data interaction with a hardware physical layer through driving, wherein the hardware physical layer is connected with each onboard network bus to realize data transmission with a sending node and a receiving node;
Step S3, configuring the platform system layer to perform task scheduling, memory management and time management, and performing data interaction with a hardware management layer;
and S4, configuring the application processing layer to analyze the data of the platform system layer, or transmitting the data group packet to the platform system layer, monitoring each network bus connected with the hardware physical layer, and generating the data group packet to be transmitted based on a monitoring result.
2. The software architecture design method satisfying the multi-node data distribution according to claim 1, wherein in step S4, the application processing layer is configured to periodically execute task functions, the task functions executed in each monitoring period including:
Step S41, receiving a data packet according to a definition rule of a sending node ICD;
Step S42, according to the definition rule of the ICD, acquiring a state identifier and original data in the data packet;
step S43, judging whether the state identifier is valid, when the state identifier is valid, taking the original data as processing data, and when the state identifier is invalid, taking preset safety data as processing data;
Step S44, the processing data is packaged and sent according to the definition rule of the receiving node ICD.
3. The method according to claim 2, wherein the step S41 is preceded by determining whether the current period is a monitoring period according to a predetermined monitoring rate.
4. The method according to claim 2, wherein in step S41, the port driver of the hardware management layer is invoked to sequentially receive all the packets of each transmitting node.
5. The method of claim 2, wherein step S43 further comprises recording a monitoring status, and filling the monitoring status and the processing data into a transmission packet memory in step S44.
6. The method according to claim 2, wherein in step S44, the port driver of the hardware management layer is invoked to transmit the packetized data to the receiving node.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311834125.XA CN117908845A (en) | 2023-12-28 | 2023-12-28 | Software architecture design method capable of meeting multi-node data distribution |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311834125.XA CN117908845A (en) | 2023-12-28 | 2023-12-28 | Software architecture design method capable of meeting multi-node data distribution |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117908845A true CN117908845A (en) | 2024-04-19 |
Family
ID=90693765
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311834125.XA Pending CN117908845A (en) | 2023-12-28 | 2023-12-28 | Software architecture design method capable of meeting multi-node data distribution |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117908845A (en) |
-
2023
- 2023-12-28 CN CN202311834125.XA patent/CN117908845A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101237345B (en) | A network management method for CAN bus | |
| US8577521B2 (en) | On-board aeronautical system with dynamic reconfiguration, associated method and aircraft carrying such a system | |
| CN112953803B (en) | Airborne redundant network data transmission method | |
| CN111596646B (en) | Train safety control system and method | |
| EP3562126B1 (en) | Architecture for wireless avionics communication networks | |
| CN113885472B (en) | High-speed railway train control vehicle-mounted equipment simulation test universal platform | |
| CN111158900B (en) | Lightweight distributed parallel computing system and method | |
| CN108199944B (en) | Onboard cabin core system of dynamic daisy chain ring network and dynamic positioning method | |
| CN108199896A (en) | Distributed message delivery system based on RabbitMQ | |
| CN106961700B (en) | Wireless communication method for dynamic remote fault-tolerant reconstruction of cluster avionics system computing resources | |
| CN108600235B (en) | Interface device and method for data exchange | |
| US20110010156A1 (en) | Simulation or test system, and associated method | |
| CN117908845A (en) | Software architecture design method capable of meeting multi-node data distribution | |
| CN108616591B (en) | Interface device and method for data exchange | |
| CN113859321A (en) | Train communication-based train automatic control system based on cloud computing | |
| CN115903578A (en) | Electromechanical management subsystem fault-tolerant design method based on hybrid redundancy heterogeneous network | |
| US20140143589A1 (en) | Method for managing path of osek networks | |
| CN116939897A (en) | 5G power gateway and data transmission method | |
| CN106445731A (en) | IMA system with dynamic reconfiguration function | |
| CN107992752B (en) | Data processing method and device and computer equipment | |
| CN114040149A (en) | Service digital intelligent evolution equipment monitoring method | |
| CN117319261A (en) | AUTOSAR-based management method, equipment and system | |
| CN104657240B (en) | The Failure Control method and device of more kernel operating systems | |
| CN105027455A (en) | Train information management device | |
| US11894905B2 (en) | Communication device and operating method therefor |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |