Amphibious aircraft alarm database design method, alarm system and alarm method

Abstract

The invention discloses an amphibious aircraft alarm database design method, an alarm system and an alarm method. Determining the alarm demand of each alarm demand side based on scenarized demand capture and confirmation; converting each alarm demand into an alarm entry with an alarm attribute, wherein each alarm entry is in a decoupling state; and finally, constructing an alarm database through the alarm entries. According to the invention, the alarm demand conversion efficiency and the alarm realization accuracy of the airplane can be improved.

Description

Technical Field

[0001] The present invention belongs to the field of aviation engineering, and in particular relates to an amphibious aircraft warning database design method, a warning system and a warning method. Background Art

[0002] With the continuous development of technology, amphibious aircraft, as a new tool and means, are gradually being applied to forest fire fighting and maritime rescue missions. The continuous improvement of the integration of avionics systems has enabled crews to experience a more intelligent driving experience. In particular, the crew warning system's awareness of aircraft status and operating environment hazards has significantly reduced the crew's mission load. Therefore, the warning system has become an increasingly critical link in ensuring flight safety. However, how to correctly implement the warning logic of all aircraft systems requires deep coordination and close cooperation among multiple disciplines, which is by no means easy to achieve.

[0003] The traditional industry practice is: 1. Through the warning system based on the central warning computer, aircraft status parameters are received via the low-frequency bus. The warning software deployed in the warning computer can uniformly meet the warning needs of various professional functions. The development process is roughly as follows: The software supplier implements coding and verification based on the alarm requirements issued by the host, and then delivers the integration and alarm computer to the host together with the equipment; After the host machine has been verified in the laboratory and on the ground to ensure that the alarm logic is implemented correctly, it is installed and flight test is carried out; When the above verification phase finds an alarm-related problem, it is necessary to analyze and troubleshoot the problem. If it is confirmed that the alarm software has a problem, the supplier needs to upgrade it again. Whether the upgrade is caused by an alarm software issue or a software upgrade due to a change in requirements, a series of laboratory verification, onboard ground verification box, and flight tests must be carried out again after the equipment is delivered, significantly increasing the aircraft development cycle. Second, if the warning request involves aircraft status parameters that have never been received, a new data forwarding cable must be added to connect it to the warning computer. If the warning computer's hardware interface is no longer available, the warning computer hardware must be redesigned, which has a greater impact on the aircraft development cycle. Third, the correct implementation of alert requirements requires careful consideration of sensor parameters, data transmission and distribution, logical operations, and appropriate feedback forms after alerts are established. Practical experience shows that the more complex the interconnections between onboard systems, the more multidisciplinary collaboration is required to implement the alert logic. Furthermore, any change in parameters or circuits will require an upgrade of the alert software, which in turn means near-endless validation of the alert system. Summary of the Invention

[0004] The purpose of the present invention is to address the deficiencies of the existing technology and provide a method for designing an amphibious aircraft warning database, a warning system and a warning method, which can improve the efficiency of converting aircraft warning requirements and the accuracy of warning implementation, while shortening the development cycle of the warning system and the aircraft.

[0005] The technical solution of the present invention is a method for designing an amphibious aircraft warning database. Based on scenario-based demand capture and confirmation, the warning requirements of each warning demander are clarified; each warning requirement is converted into a warning item with warning attributes, and each warning item is decoupled from each other; and finally, an warning database is constructed based on the warning items.

[0006] In the aforementioned amphibious aircraft alarm database design method, the alarm attributes include: alarm number, aircraft status parameters, and logical expression; the alarm number is the unique code of the alarm entry; the aircraft status parameters define the physical value and logical value of the aircraft status parameters involved in the alarm entry, and the mapping relationship between the two; the logical expression is constructed based on the logical value of the aircraft status parameters involved in the alarm entry, and is used to describe the alarm requirements.

[0007] In the aforementioned amphibious aircraft warning database design method, the warning attributes further include: the warning level is used to clarify the severity of the fault when the warning of the warning item occurs.

[0008] In the aforementioned amphibious aircraft warning database design method, the warning attributes also include: Logical description: A basic description of the logic involved in alarm implementation based on natural language.

[0009] In the aforementioned amphibious aircraft warning database design method, the warning attributes also include: The displayed text of the alarm provides feedback for perceiving the current system failure or peripheral environment danger when the alarm condition is met, and provides guidance for taking specific actions.

[0010] In the aforementioned amphibious aircraft warning database design method, the warning attributes also include: warning audio, which is used to clarify the special sound that needs to be played to the crew when the alarm occurs; and playback mode, which is used to clarify whether the warning audio is played only once or more than once when the alarm occurs.

[0011] In the aforementioned amphibious aircraft warning database design method, the warning attributes also include: whether the warning can be reset, which is used to clarify whether the warning feedback is reset through a specified operation when the warning occurs.

[0012] An alarm system constructed based on an alarm database designed based on the aforementioned design method comprises: A parameter acquisition unit, configured to convert the acquired aircraft status parameters into logical values ​​based on a mapping relationship; A logic calculation unit, configured to perform logic calculations on the logic values ​​of the aircraft status parameters according to the alarm requirements, and to identify alarm items for which the alarms are established based on the calculation results; An alarm feedback unit is used to output an alarm according to the corresponding alarm feedback form in the alarm item of the alarm establishment; The alarm database is used to store alarm entries for the parameter acquisition unit, logic calculation unit and alarm feedback unit to call.

[0013] The aforementioned alarm system further includes: A parameter conversion unit, used to convert low-speed signals in aircraft status parameters into high-speed bus signals; The parameter transfer unit is used to share high-speed bus signals with the logic calculation unit.

[0014] An alarm method for the aforementioned alarm system: after a parameter acquisition unit collects aircraft status parameters from various sensors, the aircraft status parameters are converted into logical values ​​based on a mapping relationship; a logical calculation unit performs logical calculations on the received logical values ​​according to alarm requirements, and identifies alarm items whose logical expressions represent the establishment of alarms based on the calculation results; and an alarm feedback unit outputs an alarm based on the corresponding alarm feedback form in the alarm item.

[0015] Beneficial effects: The present invention clarifies the preliminary alarm requirements of users, flight crews and various alarm demand professionals through scenario-based demand capture and confirmation, and then converts the personalized requirements of various alarm demand parties into alarm items with a series of alarm attributes that can be implemented by downstream software suppliers through attributed alarm demand conversion, and finally completes the design of the alarm database; the present invention systematically designs and constrains the alarm logic of the entire aircraft in a scenario-based, item-based and attributed manner through the design of the alarm database, and accurately manages the alarm logic of the entire aircraft through process-based and generalized management, effectively improving the iteration efficiency of the alarm logic throughout the entire life cycle of the aircraft, shortening the aircraft development cycle, and improving the aircraft's alarm demand conversion efficiency and the accuracy of alarm realization, ultimately achieving the purpose of improving aircraft safety, enhancing user experience and accelerating the development of alarm system technology.

[0016] The present invention clarifies the alarm requirements of each alarm demander through scenario-based demand capture and confirmation; this method can create an alarm database model adapted to amphibious flight scenarios, which is conducive to shortening the system development and certification cycle and providing underlying support for the execution of complex tasks.

[0017] The present invention converts each alarm requirement into an alarm item with multiple alarm attributes, which is beneficial to unifying the alarm top-level protocol and standardizing the multi-level alarm priority and triggering threshold.

[0018] The warning system of this invention can effectively reduce false alarm rates, enhance crew confidence in the warning system, and ensure a response within seconds in the event of a real fault. Engineering simulation tests have proven that it can reduce the risk of potential flight accidents by 27%.

[0019] The present invention can support flexible adaptation of amphibious aircraft of different tonnage levels, can realize dynamic adjustment of architecture through adaptive increase and decrease of hardware and parameterized configuration of database, and has strong adaptability.

[0020] The implementation threshold of this invention is low, and standardized interfaces and lightweight algorithms can be used. Compared with traditional solutions, the deployment efficiency is improved by 40%. It has been verified by the principle prototype of a certain type of amphibious aircraft.

[0021] The present invention has strong industry compatibility and can be extended to fields such as civil transport aircraft and special operation aircraft, and has the potential for promotion in all scenarios of aviation engineering.

[0022] This invention shortens the development and certification cycle of the alarm system by 35%, improves demand transmission efficiency by 50%, reduces the false alarm rate by 62%, and increases the alarm confidence level to 98%. The present invention can form a reusable amphibious aircraft warning technology system, providing all-weather safety protection for special tasks such as forest fire fighting and maritime rescue.

[0023] In addition, compared with the traditional method, the present invention has the following advantages: 1. Multi-disciplinary collaboration: This system uniformly and formattively screens and identifies the logic, status parameters, conditions for alarm formation, and feedback information after an alarm is established. This allows for the assessment of the impact on the correctness of the entire aircraft's alarm software when related professional design changes occur. 2. Timely response to demand changes: Different disciplines have different levels of technical maturity, resulting in different exposure times for equipment problems within their disciplines. This invention further subdivides the granularity of alarm requirements by attributing alarm items, accurately identifying and conducting feasibility analysis, and promptly responding to the continuous iteration of alarm requirements; 3. Technical Status Freeze: From the perspective of alarm implementation, based on the importance and urgency of the various professional alarm requirements on board, specific alarm requirements are implemented in a targeted manner without affecting the validity of other unchanged alarm verification tests, decoupling the verification tests of various disciplines from related compliance activities; 4. On-demand integration of all machine data: Based on a configured bus network, all machine status parameters can be shared, enabling on-demand alarms. Compared to traditional methods with a change cycle of three months or even more than six months, this invention can shorten the parameter sharing cycle to less than one month. 5. Helps Demonstrate Conformity: Due to the involvement of flight safety, the airworthiness activities of warning systems are often more rigorous and conservative. Therefore, during the early planning process of warning system airworthiness activities, the itemized warning verification plan can more intuitively demonstrate the completeness and rationality of the content verification; during the verification phase, the itemized warning makes it easier to control the verification progress; and during the system's compliance demonstration phase, the itemized warning implementation method makes it easier for applicants to collect and organize relevant compliance evidence. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 This is the architecture diagram of the alarm system of the present invention; Figure 2 It is the technical path to realize the alarm system with the participation of all alarm demand parties. DETAILED DESCRIPTION

[0025] Example 1. A method for designing an amphibious aircraft warning database, based on scenario-based demand capture and confirmation, clarifies the warning requirements of each warning demander; converts each warning requirement into a warning item with warning attributes, with each warning item being decoupled; and finally constructs a warning database using the warning items.

[0026] The crew warning system is an onboard system used to promptly feedback abnormal conditions onboard to the flight crew and assist the crew in taking appropriate disposal measures in a timely manner. The implementation of the onboard warning function requires the combination of aircraft status parameter perception, transmission and logical calculation, and feedback in a specified form when the warning condition is met. Usually, the implementation of the warning logic involves more than ten disciplines such as full aircraft power, power supply, flight control, hydraulics, landing gear, etc., with a total of several thousand status parameters. Changes in the design status of the above-mentioned disciplines will lead to subsequent changes in the software of the warning system, which will bring difficulties to the technical freeze of the warning system, and thus affect the airworthiness and delivery operation nodes of the aircraft. The present invention will change the attributes of each alarm item, and the attributes of an alarm item will not affect other alarm items.

[0027] Through scenario-based demand capture and confirmation, top-level alarm implementation principles can be formulated based on comprehensive considerations such as the expected usage scenarios of the aircraft design and the pilot's task load: for example, the data priority principle (which of the two values ​​representing the same state parameter has higher validity) and the consistency principle (the alarm colors designed for alarms representing the same degree of urgency should also be consistent).

[0028] The aforementioned alarm attributes include: alarm number, aircraft status parameters, and logical expression; the alarm number is the unique code of the alarm item, which is used to trace the changes of the alarm requirements in the future; the aircraft status parameters define the physical value and logical value of the aircraft status parameters involved in the alarm item, and the mapping relationship between the two; the logical expression is constructed based on the logical value of the aircraft status parameters involved in the alarm item, and is used to describe the alarm requirements to facilitate the subsequent implementation and verification of the alarm logic. The logical operators in the logical expression include "and", "or", "not", and "equal".

[0029] The aircraft status parameters are captured by using corresponding sensors to provide real-time feedback on the aircraft status parameters, including voltage, current, vibration, frequency, Hall, displacement, temperature, humidity and other sensors, and converting the actual status parameters of each aircraft system into corresponding electrical signals to facilitate parameter processing and sharing in subsequent aircraft systems.

[0030] Generally speaking, the implementation of alarm logic can be divided into demand initiators, implementation stakeholders, implementers, and software implementers and verifiers based on the roles involved in the implementation. The demand initiator proposes specific alarm requirements based on the aircraft operation and use requirements, airworthiness standards, etc. The implementation of the alarm requirements often involves the participation of stakeholders in the implementation of the alarm. For example, the aircraft takeoff configuration alarm, the initiator of its requirements often comes from the overall professional field of aircraft development, while the implementation stakeholders often include professionals such as power, system and avionics. After clarifying the specific requirements and the required status parameters, the alarm implementer will pass the confirmed requirements in the form of an alarm database to the alarm software implementer. The implementer will reconfirm the requirements to ensure that the final implementation of the alarm meets the use requirements of the demand initiator. In order to ensure the accuracy of the software implementation, an independent third party - the software verifier - is often required to conduct multi-dimensional verification of the implemented alarm software, such as function and code walkthrough, before the software is delivered to the user for use. As can be seen from the above, the implementation of the entire alarm logic requires the participation of multiple parties, and the process is complicated. See. Figure 2 ; In order to overcome this technical problem, the present invention forms an alarm item with multiple attributes based on the alarm requirements of the aircraft; the alarm logic in the alarm item can transfer the requirements between the internal demand profession and the alarm profession, and can also transfer the alarm calculation requirements to the software implementer to the external software implementer; this method is convenient for realizing process-based and universal management and control, shortening the aircraft development cycle, improving the efficiency of converting the aircraft's alarm requirements and the accuracy of alarm implementation, and ultimately achieving the purpose of improving aircraft safety and enhancing user experience.

[0031] The aforementioned alarm attributes also include: Alarm level is used to clarify the severity of the fault when the alarm of the alarm item occurs. According to airworthiness regulations, red usually represents warning level, and amber or yellow represents alert level.

[0032] The aforementioned alarm attributes also include: logical description, which provides a basic description of the logic involved in alarm implementation based on natural language.

[0033] The aforementioned alarm attributes also include: Alarm display text, when an alarm condition is met, provides feedback to the crew regarding the current system failure or environmental hazard, and guides the crew in taking specific actions. Specifically, alarm display text is a meaningful set of words, characters, and / or numbers displayed in a designated area when an alarm condition is met, providing visual feedback to the crew. This provides accurate feedback to the crew regarding the current system failure or environmental hazard, and provides precise guidance for taking specific actions. Examples of alarm text include "INS 1 Failure" and "RA2 Failure."

[0034] The aforementioned alarm attributes also include: Alarm audio, used to specify the special sound that needs to be played to the crew when an alarm occurs, such as conventional single chime, double chime, and special alarm tone Speed; Playback mode is used to specify whether the alarm audio is played only once or more than once when an alarm occurs.

[0035] The aforementioned alarm attributes also include: whether the alarm can be reset, which is used to clarify whether the alarm feedback can be reset through a specified operation when the alarm occurs. Specifically, the alarm attribute of whether the alarm can be reset clarifies whether the crew can reset one or more alarm feedback forms, including but not limited to the alarm display text and / or alarm audio, through specified operations (including but not limited to pressing the indicator light switch) when the alarm occurs. For example, when resetting the alarm display text, the display text content disappears after the reset; when resetting the alarm audio, the alarm audio stops playing after the reset.

[0036] Based on the warning logic formed by the warning requirements, when the warning system determines that a warning has been issued based on the received status parameters, the warning feedback forms include but are not limited to visual, auditory, tactile, and a combination of two or more forms. Among them, visual warnings include but are not limited to warning lights, warning text, warning flags, special symbols on monochrome displays, etc.; auditory warnings include but are not limited to monotonous homophones and voices with specific semantics, and the playback forms of auditory warnings include but are not limited to single playback and repeated playback. Based on the driver's handling method, the auditory warning sound can be divided into resettable and non-resettable. Tactile warnings include but are not limited to vibration and heating.

[0037] Based on the above-mentioned alarm database design method, the design team can customize the alarm establishment conditions, alarm feedback methods, and clarify the aircraft status parameters involved in each alarm, as well as the state range value that each state parameter needs to reach when the alarm is satisfied. The realization of the alarm requirement is to convert the aircraft state parameters (x1, x2...x n ) to be collected, identified and received, and implemented according to the alarm requirements: It can be simplified into the following expression: y=f(x1, x2…x n ) Where x1, x2...x n The aircraft status parameters, specifically the status parameters related to this warning; f() is the warning requirement, which will clearly indicate the aircraft status parameters x1, x2...x n Under what range or change trend will the alarm condition be met and the alarm result y be obtained; at the same time, the alarm requirement also includes the alarm feedback form after the alarm is established. Different feedback forms can represent alarms of different urgency.

[0038] An alarm system built on the alarm database designed based on the above design method, see Figure 1 ,include: A parameter acquisition unit, configured to convert the acquired aircraft status parameters into logical values ​​based on a mapping relationship; A logic calculation unit, configured to perform logic calculations on the logic values ​​of the aircraft status parameters according to the alarm requirements, and to identify alarm items for which the alarms are established based on the calculation results; An alarm feedback unit is used to output an alarm according to the corresponding alarm feedback form in the alarm item of the alarm establishment; The alarm database is used to store alarm entries for the parameter acquisition unit, logic calculation unit and alarm feedback unit to call.

[0039] Specifically, the logic calculation unit will form a parameter pool with the received full machine status parameters, and then perform logic calculations based on the alarm logic requirements proposed by the demand professionals. Based on the calculation results, it will identify the alarms for which the alarm conditions are met, and send the corresponding alarm feedback form in the form of instructions to the corresponding alarm feedback unit; Specifically, the warning feedback unit sends corresponding feedback instructions to the sound playback unit, visual display unit and vibration unit according to the received warning feedback instructions and the warning requirements of each profession. Among them, the sound playback unit feeds back the warning audio associated with the warning to the driver, and the vibration unit transmits the warning information to the driver through vibration. The visual display unit transmits the warning to the driver in a visual manner. The corresponding visual feedback form can be further divided into warning lights, warning texts and warning symbols, and the warning information conveyed by the warning lights, texts and symbols should be consistent to avoid interference with the driver. In addition, the display of lights and texts should also follow unified standard requirements.

[0040] This invention integrates alert feedback formats (alert audio, displayed text, alert level, playback format, etc.) into alert entries through alert attributes. This method facilitates clear top-level principles for alert feedback formats. Within the alert database, each specific alert must clearly identify its assigned alert level, and based on that level, its assigned alert feedback format. Furthermore, according to airworthiness standards, different alert levels should have different feedback formats. Warning-level alerts require a more urgent feedback format, alert-level alerts a less urgent one, and prompt-level alerts can use only one feedback format. This method facilitates this distinction.

[0041] Specifically, the alarm database, based on the alarm requirements of each discipline, organizes each alarm into items, including the displayed alarm text, lighting color, audio content, and playback format. Simultaneously, an alarm logic library is compiled to ensure the accurate implementation of every alarm requirement in the alarm database. As a core component of the alarm system, the alarm database receives alarm requirements from various parties and manages them in a standardized format. It also provides design input and basis for implementers and verifiers of alarm software. Furthermore, the alarm database provides visual, itemized requirements documentation for system review by auditors.

[0042] In the present invention, the alarm database uses the alarm entry as the smallest management unit. The alarm database will define a series of contents such as the alarm number, logical description, alarm sound content, alarm sound playback format, displayed alarm text, etc. of each alarm entry, and will perform unified attribute definition and change management.

[0043] The aforementioned alarm system also includes: A parameter conversion unit, used to convert low-speed signals in aircraft status parameters into high-speed bus signals; The parameter transfer unit is used to share high-speed bus signals with the logic calculation unit.

[0044] Considering the complexity of aircraft system interconnection, increasing signal transmission distance and anti-interference capabilities, and reducing the weight of transmission cables between devices, the alarm system of the present invention adds a parameter conversion unit and a parameter transfer unit between the acquisition unit and the logic calculation unit. The parameter conversion unit is responsible for converting low-speed signals (such as analog and discrete quantities) at the far end of the aircraft into high-speed bus signals with strong anti-interference capabilities and long transmission distances. The high-speed bus signals are then shared with the logic calculation unit via the parameter transfer unit. Therefore, the necessity of the parameter conversion unit and the parameter transfer unit depends on the architecture of the designed alarm system, as well as the parameters such as transmission distance limitations and anti-interference requirements, and how they are processed, forwarded, and further transmitted and shared within the alarm system.

[0045] The alarm method of the aforementioned alarm system: after the parameter acquisition unit collects the aircraft status parameters from each sensor, the aircraft status parameters are converted into logical values ​​based on the mapping relationship; the logical calculation unit performs logical calculations on the received logical values ​​according to the alarm requirements, and identifies the alarm items whose logical expressions represent the establishment of the alarm based on the calculation results; the alarm feedback unit outputs the alarm according to the corresponding alarm feedback form in the alarm item.

[0046] Some of the aircraft status parameters (such as the aircraft's calibrated airspeed, etc.) are comprehensively calculated by computers within each system and shared as needed to the logical calculation unit within the alarm system. After these status parameters are uniformly received by the alarm system, the logical calculation of the aircraft's relevant alarms is realized according to the preset alarm calculation logic. Based on the calculation results, the corresponding alarm information is promptly fed back to the driver when the alarm is established.

[0047] Example 2. This method is described below using a surface takeoff configuration warning as an example.

[0048] According to the overall professional requirements of the aircraft, it is necessary to monitor the unsafe takeoff state of the aircraft during water takeoff - the flaps are not in the safe takeoff position. The alarm logic is described as follows: When the aircraft takes off from the water, the flaps are not in the water takeoff configuration Number: SQF_1.

[0049] Display text: Flaps.

[0050] Logic description: Water takeoff: The flaps are not in the water takeoff configuration. The water takeoff status is: a) The aircraft is on the water (the aircraft has no wheel load, RA < 5m, and the calibrated airspeed ≤ 190km / h, and the landing gear is retracted), and b) The engine is at takeoff power (the throttle handle is pushed to the takeoff position - the throttle angle is greater than 68 degrees), and c) The calibrated airspeed is less than the decision speed (V 1W, the default surface decision speed is 180km / h) The flap takeoff position on water surface is: 20°±1°.

[0051] Logical expression: Y==F(y 襟翼 ,y 油门角度 ,y 速度 ,y 飞机状态 ),in: y 襟翼 =f1(x 襟翼 ), the law f1() is that the flap position does not belong to the safe takeoff angle; y 油门角度 =f2(x 油门角度 ), the law f2() is the throttle angle greater than the throttle angle corresponding to the takeoff power; y 速度 =f3(x 速度 ), law f3() is that the current airspeed of the aircraft is less than the decision speed; y 飞机状态 =f4(x 飞机状态 ), the law f4() is that the aircraft state is on the water surface.

[0052] Alarm level: Warning level.

[0053] Audio ID: VTC_1.

[0054] Audio Content: Takeoff flaps.

[0055] Play mode: Repeat play.

[0056] The signals involved in flap warning implementation include but are not limited to the parameters shown in the following table: Serial number variable name range Accuracy unit Specification No. signal name Bit 1 flap angle 0～35 0.1 Spend <![CDATA[A 6096 / FECU-001-L158]]> Flap position 13-28 2 Front wheel load status 0: air, 1: ground NA NA <![CDATA[A 6096 / PCU-001-L161]]> PDU outputs landing gear, door and wheel position information 13 3 Main hoist load status 0: air, 1: ground NA NA <![CDATA[A 6096 / PCU-001-L161]]> PDU outputs landing gear, door and wheel position information 15 4 Calibrated airspeed 0～600 0.1～5.8 km / h <![CDATA[A 6096 / ADS-L021]]> Corrected airspeed 13-28 5 Throttle angle 0～100 0.1 Spend <![CDATA[A 6096 / RDC-L211]]> Throttle angle 13-19 6 Radio altitude -10～3000 0.5 rice <![CDATA[A 6096 / RA-L221]]> Radio altitude 13-29 The realization of the above-mentioned alarm requirements involves supporting disciplines including: flight control discipline (providing flap angles), navigation discipline (providing radio altitude and calibrated airspeed), power discipline (providing throttle angles), and landing gear discipline (providing wheel load information). In addition, the collection and forwarding of the above-mentioned aircraft status parameters also involves two disciplines: electromechanical parameter collection and network data configuration. When the alarm conditions are met, the corresponding text display (display and control discipline) and alarm sound (communication discipline) are generated, as well as the alarm discipline that accepts alarm requirements, accepts status parameters and performs logical calculations.

[0057] After multiple rounds of coordination and iteration, the aforementioned warning item—the flaps (surface takeoff configuration warning)—was finally formed. The remaining warning items in amphibious aircraft were also implemented based on this method.

Claims

1. A method for designing an amphibious aircraft warning database, characterized in that: Based on scenario-based demand capture and confirmation, the alarm requirements of each alarm demander are clarified; each alarm requirement is converted into an alarm item with alarm attributes, and each alarm item is decoupled; finally, an alarm database is constructed through the alarm items.

2. The method for designing an amphibious aircraft warning database according to claim 1, characterized in that: Alarm attributes include: alarm number, aircraft status parameters, and logical expression; the alarm number is the unique code for the alarm entry; the aircraft status parameters define the physical value and logical value of the aircraft status parameters involved in the alarm entry, and the mapping relationship between the two; the logical expression is constructed based on the logical values ​​of the aircraft status parameters involved in the alarm entry and is used to describe the alarm requirements.

3. The method for designing an amphibious aircraft warning database according to claim 2, characterized in that: The alarm attributes also include: the alarm level is used to clarify the severity of the fault when the alarm of the alarm item occurs.

4. The method for designing an amphibious aircraft warning database according to claim 2, characterized in that: Alarm attributes also include: Logical description: A basic description of the logic involved in alarm implementation based on natural language.

5. The method for designing an amphibious aircraft warning database according to claim 2, characterized in that: Alarm attributes also include: The displayed text of the alarm provides feedback for perceiving the current system failure or peripheral environment danger when the alarm condition is met, and provides guidance for taking specific actions.

6. The method for designing an amphibious aircraft warning database according to claim 2, characterized in that: Alarm attributes also include: Alarm audio, used to specify the special sound that needs to be played to the crew when an alarm occurs; Playback mode is used to specify whether the alarm audio is played only once or more than once when an alarm occurs.

7. The method for designing an amphibious aircraft warning database according to claim 2, characterized in that: Alarm attributes also include: whether the alarm can be reset, which is used to clarify whether the alarm feedback can be reset through a specified operation when the alarm occurs.

8. An alarm system constructed based on an alarm database designed by the design method according to any one of claims 1 to 7, characterized in that: include: A parameter acquisition unit, configured to convert the acquired aircraft status parameters into logical values ​​based on a mapping relationship; A logic calculation unit, configured to perform logic calculations on the logic values ​​of the aircraft status parameters according to the alarm requirements, and to identify alarm items for which the alarms are established based on the calculation results; An alarm feedback unit is used to output an alarm according to the corresponding alarm feedback form in the alarm item of the alarm establishment; The alarm database is used to store alarm entries for the parameter acquisition unit, logic calculation unit and alarm feedback unit to call.

9. The alarm system according to claim 8, characterized in that: Also includes: A parameter conversion unit, used to convert low-speed signals in aircraft status parameters into high-speed bus signals; The parameter transfer unit is used to share high-speed bus signals with the logic calculation unit.

10. An alarm method of the alarm system according to claim 8 or 9, characterized in that: After collecting aircraft status parameters from various sensors, the parameter acquisition unit converts the aircraft status parameters into logical values ​​based on the mapping relationship. The logic calculation unit performs logical calculations on the received logical values ​​according to the alarm requirements and identifies the alarm items whose logical expressions indicate the alarm is established based on the calculation results. The alarm feedback unit outputs an alarm according to the corresponding alarm feedback form in the alarm item.

Images