unless otherwise stated , in the description and the figures , the symbols , acronyms and abbreviations have the meanings indicated in the table below . fig1 represents the relationships of a warning management system with the other onboard systems . the fws system is implemented redundantly on two computers of the ima ( integrated modular avionics , able to be implemented on a power pc computer ) architecture , in which the consistency of the output is checked at each computation step . each computer fws / fwa therefore has for input those from the dual computer in the corresponding step and also sends it its own results . furthermore , the fws receives as input the a / c data ( i . e . : the discretes from the onboard computers used to detect the failures of an electronic equipment connected thereto ) and the dca data on n channels ( making it possible to correlate the failures with each other ). finally , four systems advantageously send their output to the fws computer : the output from the control panel of the centralized monitor subsystem of the airplane electronics ( ecp / ecam ) which return the pilot actions ( item acknowledgement , movement in the check list , access to system pages and to procedure lists ); the states of the notification and warning c / w button at the output of the fws system ; the output from the terrain and aircraft avoidance system t2cas ; this system manages the positioning of the aircraft relative to the relief and relative to the trajectories of other detected aircraft and sends warnings to the fws system in case of a collision trajectory ; the output from the meteorological radar wxr system ; these output are used to trigger warnings on severe bad weather . these data are conditioned for use by the fws system (“ input processing ” function ). crew warning , status management and a / c warning logics are implemented to process the input data , the processed data being supplied to the fws generic function core . the crew warning logics are dedicated to the triggering of current warnings specific to a given item of equipment . when producing a check list ( triggered by the first type of logic ), the status logic induces a status check list . the a / c warning logics are identical to the first type of logic , but are generic to a set of computers and not to a single computer . the parameters of the current flight phase are also supplied to the fws core . the fws core is advantageously partitioned into three management functions ( crew warnings , states and check list ) and four output warning management functions ( cas / ckl zone managing warnings that have been triggered and that induce a check list procedure , inop sys managing the warnings that are triggered and filtered and do not induce either a warning or a procedure — only the inop sys indicator will be seen by the crew , audio warnings , c / w button warnings ). the audio warnings are selected from an audio message database provided for this purpose . the visual warnings are displayed on the screens provided for this purpose in the cockpit and the flight deck . the arinc 661 and tftp protocols make it possible to communicate with the cds ( cockpit display system ). the cmf protocol makes it possible to send failure data to the centralized maintenance system , to trace all the anomalies detected during the flight ; management of severe weather avoidance procedures ( swaps ): a tool to help in implementing procedures specific to north american airspace decreed by the faa and triggered by air traffic control if there is a need for rerouting , notably in cases of severe storms or cyclones . fig2 represents the simplified functional architecture of a warning management system according to the invention . a data acquisition module 10 groups together the parameters needed to evaluate the operation of the supervised systems . it can concern intrinsic data ( malfunction of an item of electronic equipment or an engine , cabin pressure , altitude , speed , etc .) or extrinsic data ( output from the collision avoidance system , output from the weather system , message from the airline , control message , etc .). it is also possible to envisage the data acquisition module acquiring the data modified by the crew in response to a warning and so enabling the execution of a procedure to be validated in closed loop mode . a failure detection module 20 analyzes these supervised data to deduce therefrom the detection of failures that are stored in a failure listing . the commands executed by the crew generate an action listing . the failures stored in the failure listing trigger , where appropriate , a master warning , master caution ( mwc ) action 30 , generally in the form of a visual signal from the corresponding button , possibly accompanied by an audio message , all under the control of the mwc module &# 39 ; s behavior logic . the actions to be carried out by the crew are displayed via the human / machine interface ( hmi ) module 40 in the form of procedures listed in pages . a standard procedure is to require the crew to acknowledge the consultation of the pages listing the procedures to be carried out in the case of a current warning . the actual sequencing is handled by the priority management and task management functions combined in the task scheduling module 50 . this scheduling module comprises the software components used to trigger the warnings specific to each failure and provide the users with the associated procedures according to criteria defined in the different versions of the fws system . as detailed hereinbelow , a task is a warning / procedure pairing which also comprises other attributes . the “ task ” object is used to handle the scheduling at a more detailed level than that of the procedure , which is the level of scheduling of the fws systems of the prior art . the parameters for scheduling the fws system warning processing tasks that are specific to given operating conditions of an aircraft are loaded into a configuration table 60 and used by the failure detection module ( display style , text of the procedure items , structure of the procedures , links between procedures , unique task identifier ). all the static data known a priori are in the configuration table ; all the data describing the system &# 39 ; s execution dynamics are not described in the configuration table , but are part of a meta - model described in the commentary to fig4 . from the input data of the module 10 , the failure detection module 20 applies the logics used to determine the task identifiers . the configuration table can easily be updated in an operator maintenance operation or during a simple stopover , by downloading from a database qualified as do200 . the loading is performed simply with no need for program recompilation , the prior parameters being simply overwritten by the new parameters by ground / onboard file exchange by ftp or tftp protocol during centralized maintenance operations . the data to be loaded are generated by an xml module . the scheduling module includes a generic data model that is not modified in the various instantiations of an fws system developed for an aircraft that has a given hardware and software configuration . the model is made up of tasks to be carried out by the system according to prescribed behaviors or rules . the behaviors or rules are used to process the connections from ( failure characteristic data ) and to ( generation of warnings and application of corresponding procedures ) outside the system . these behaviors can change from one version to another . they are stored in the system &# 39 ; s configuration table . the rules are applied directly to the tasks , on the one hand to implement the management logic for the priorities defined in the system ( priority management function ), on the other hand to take into account the actions of the user on the data model ( task management function ). the priority management logic can be defined for example at three levels , plus a conflict resolution rule in cases of equal priority , for example the order of arrival . the scheduling module or the sequencer of the fws receives triggers and applies behaviors that are used to process the system tasks . for each type of failure , the “ failure detection ” module checks whether the failure triggering conditions are fulfilled and updates the failure listing accordingly . the “ priority management ” module activates or deactivates the tasks according to the updates to the failure listing . the “ interaction command with acquisition ” module updates the action listing as soon as the user performs an action on the ecp . the “ task management ” module uses this action listing to change , for example , the internal states of the current task ( change page , validate an item , etc . ), or to change the current task . the sequencer also manages transmittals to the notification / warning system ( c / w ) and the updates to the user interface ( hmi ). the display of the warning information on the user interface ( ewd or emergency warning display ) is standardized ( arinc 661 standard ). it comprises a control panel for the elements of the cas ( crew alert system ) and a control panel for the procedures corresponding to these cas . the tasks can be subdivided into subtasks . to perform multiple - choice procedures , each choice is represented by a subtask having the same priority as the task from which it derives . the sequencer displays the tasks to the user in the order in which they must be executed , given the priority levels defined or resulting from the order of arrival . a sequencer control process rotates with a determined frequency of the order of 50 ms . the dimensioning of the system depends notably on the power of the computer and the responsiveness of the bus . the sequencer control process modifies the internal status of the tasks of the model based on user input and aircraft data . fig3 represents the operating logic at the level of a task according to an embodiment of the invention . emergency : urgent task ( linked to a priority failure placing the airplane in danger ) normal : normal task ( linked to a routine check list corresponding to the pilot actions of a flight phase ) abnormal : abnormal task ( linked to a non - priority failure not placing the airplane in danger but having to be dealt with ) status : status update task ( linked to a summary of a completed abnormal task ) consultation : consultation task ( any emergency , normal or abnormal task , in free consultation mode , that is to say , not triggered by the system ) cleared : task active but hidden from the user at the request of the user active : task active ( failure triggered in the system ) in_progress : active task currently executing ( presented to the user ) completed : task completed consulted : task consulted as already indicated , the tasks can comprise subtasks that have their own attributes , notably their status and their task dependency link . each task is linked to a warning ( casitem ) identified by a message character string . the display of casitem can be parameterized by a style sheet which can be selected with a default format or configured differently . the display of the data in the style sheet can be parameterized using an xml file . each task is also linked to a procedure ( procedure ) identified by one or more character strings . since the display of the procedures is paginated , each of the pages that displays a procedure is identified by an index ( pageindex ). a number of status indicators can also be provided as attributes of a procedure , notably a status variable indicating whether all the items of the procedure have been checked ( allitemschecked ) and whether the procedure has been completed ( iscompleted ). the checking of the procedure pages and , on each page , of each item , can also be followed by status variables . on each procedure page , each line ( line ) can also be identified by a label . each procedure item can be identified by a category to which it belongs ( procedureitemcategory ) which can , for example , take the following values : action : action item that can be validated by the user memo : text item proc_completed : item indicating that the procedure has been completed previous_page : action item used to access the previous page next_page : action item used to access the next page empty : empty item the operation of the method of managing warnings onboard an aircraft is illustrated by the application to a warning case illustrated on the screen shot in fig4 . this example is by no means limiting on the possible embodiments of the invention : on the left : elec smk represents a warning ( cas item ) that has been detected . on the right : the procedure corresponding to the warning on the left is presented to the pilot . the first 2 lines represent a memo item ( non - interaction information ); the third and fourth lines represent action items validated by the pilot ; the framed line represents the current item that can be validated ; the following lines represent the action items that have not yet been validated ; the lines with if represent a multiple choice . the validation of one of these items will lead to the selection of the corresponding subtask . the structuring of the fws system according to the invention as has just been described makes it possible to organize the developments in such a way as to factorize a large portion of the software code lines . the portions that depend only on the hardware configuration of the external modules and on the software configuration common to a type of aircraft without depending on the variable specifications of the aircraft manufacturer , are implemented in the scheduling module . the portions that closely depend on the operational conditions of use specific to an operator , such as the assignment of priority levels to tasks , the content of the procedures , the display style sheet and the task and display execution logic , notably , are processed as parameters that are stored in a configuration table . these portions can be programmed using a high - level language , such as xml ( extended mark - up language ). a software development workbench can be used to manage this distribution of the processes and data . certification can be obtained with an initial configuration . it will not be necessary to recertify the future changes to the fws system with a modified configuration table , given that it can be proven that modifying the table in no way changes the behavior of the system . such will be the case if the software development workbench is compatible with the do200 standard . to make a modification to the configuration table , all that is needed is to generate one or more xml files which will be converted by the development workbench into the structure of the configuration table . two different types of xml files are generally used , a first type that describes the style sheet applicable to the data and a second type comprising the description of all the data needed for the processing of the tasks by the sequencer . the loading operation can then be carried out in a simple operation maintenance procedure when the aircraft is immobilized at a gate by using the tools provided for this purpose ( trivial file transfer protocol , tftp , or other protocol offering the same procedures for acknowledging downloads to the ima computer ). the examples described hereinabove are given to illustrate embodiments of the invention . they in no way limit the scope of the invention which is defined by the appended claims .