FR3031407A1 - VEHICLE CONTROL SYSTEM, IN PARTICULAR AIR - Google Patents

Abstract

An on-board control system of a vehicle includes a control unit (12) comprising a computer and configured to receive information from a plurality of peripheral modules (18i) and conduct a mission based on that information. At least one of the peripheral modules (181) is configured for, by means of at least one dedicated sensor, performing a main function and, on request, performing a predetermined secondary function corresponding to the main function of another peripheral module (182). ). The purpose of a guarding process is to check the operating status of each of the peripheral modules and, in the event of a peripheral module failure, to evaluate the possibility of carrying out the mission in a degraded mode, in particular by activating a secondary function. in a non-defective peripheral module, for use by the control module in substitution of the main function data of the defective peripheral module.

Description

The present invention relates to the field of onboard control systems for vehicles, particularly for aircraft and more particularly for drones.

State of the art As is known, drones are now very popular and used in many applications from military to children's games, through services such as aerial photography, inspection of works, topography etc. In many of these applications, UAVs are small in size or small, with little room for embedded electronics. In the interest of compactness, in order to minimize the space required for the electronics of the flight and navigation system, closed and integrated systems have conventionally been developed in order to reduce the size, the weight, the wiring and the connections. .

In the same vein, conventional UAV flight systems are designed to be simple and generally without redundancy. Thus, many of the UAV control systems are unsophisticated, without redundancy, and have little ability, or even incapacity, to manage or assimilate failures of the control functions of the aircraft during a mission. OBJECT OF THE INVENTION The object of the present invention is to provide an improved control system for vehicles, in particular for aircraft and drones.

GENERAL DESCRIPTION OF THE INVENTION The invention is particularly interested in the architecture of an on-board control system and in particular provides a system whose architecture is modular and secure.

The present invention relates to an onboard control system of a vehicle comprising: a control unit comprising a computer; a plurality of peripheral modules each performing a particular principal function, each peripheral module comprising at least one dedicated sensor providing the measurements to fulfill its main function; the control unit being configured to receive data from the peripheral modules and to conduct a mission based on these data. According to the invention, at least one of the peripheral modules is configured, by means of its sensor, to perform its main function and, on request, to perform a predetermined secondary function corresponding to the main function of another peripheral module of the system. In addition, the control unit is configured to implement a guarding process whose function is to: check the operating status of each of the peripheral modules and, in the event of a peripheral module failure, evaluate the possibility, and if necessary decide to perform the mission in a degraded mode, by activating a secondary function in a non-defective peripheral module, to be used by the control module in substitution of the main function data of the defective peripheral module. The on-board control system according to the invention therefore has an innovative architecture that exploits a guardian process configured to react with the rest of the architecture. A particularly interesting aspect also is the use of certain peripheral modules which are designed to determine information corresponding to a main function, and perform a predetermined secondary function corresponding to the main function of another peripheral module of the system.

As an example, assume that the present system is integrated into an avionics system, which will then typically include a plurality of peripheral modules such as; GPS, altimeter, IMU, HRS, etc. The main function of the GPS module is the determination of position, and thus delivers under this main function the position of the aircraft. The main function of the altimeter is altitude determination. To function in the context of the present invention, the GPS module is preferably configured to be able to also determine the altitude of the aircraft. The guarding process, which knows the main and secondary functions of the different modules, can therefore, in the event of failure of the altimeter module, activate the secondary function of the GPS module to use the altitude information instead of that of the faulty altimeter module. In conventional avionics systems, the principle of redundancy is generally used on critical modules; if a sensor becomes faulty, there remain one or two others dedicated to the same function. In drones, on the other hand, redundancy is often not possible for reasons of space, cost, weight and energy consumption. The system according to the invention is therefore particularly advantageous because the secondary function of a peripheral module will allow the mission to continue by delivering information corresponding to the main function of another peripheral module. However, since the accuracy of this secondary function will generally be lower than that of the faulty module, (for example, the altitude measurement using GPS is less accurate than with the altimeter), the system is then " degraded mode ". The conduct of the mission in degraded mode will generally involve the adjustment of certain parameters of the system, in order to take into account the reduced accuracy when using the secondary function data.

Preferably, when no non-faulty peripheral module having a secondary function capable of replacing the defective peripheral module is found, the guardian process evaluates the possibility of continuing the mission with the complete loss of the defective peripheral module; and in particular, if the mission can not be continued without said defective peripheral module, the guarding process triggers an emergency stop procedure. In addition, if the mission can be continued without said defective peripheral module, in a degraded control mode, then the guardian process invites the user to decide whether to continue the mission or to terminate it.

As soon as an inconsistency of a peripheral module is detected, the guardian process advantageously triggers an error situation recovery routine, preferably comprising at least one of the following actions: restart of the sensor or of the peripheral module, resetting the communication with the peripheral module, asks the other peripheral modules for their communication status. In the system, at least one peripheral module is configured to perform at least one other secondary function corresponding to the primary function of another peripheral module of the system. Peripheral modules are usually in the form of an electronic card.

In practice, an application process corresponding to each peripheral module is executed in a dedicated partition of the memory of the control module. For application to avionics, the system comprising at least a portion of the following peripheral modules: IMU, GPS, HRS, altimeter, pitot, Doppler radar, and each of these peripheral modules is configured to operate a main function and to less a secondary function. The present invention is particularly advantageous in its application to the control systems of avionics. Of particular note are the following aspects. 30 Robustness. Most of the small autopilot systems for civil uses (especially for drones) are highly integrated and have only one overall process (interface with external devices, attitude determination algorithms, control systems, management of TM / TC communication, etc.). These systems are neither robust nor fault tolerant. The present invention, using different processes running in parallel, can operate in degraded mode even with the loss of one or more devices (peripheral modules). The guardian process has a supervisory and master role in the architecture by monitoring the proper functioning of the control system. The action of the guardian process in this architecture is essential for: checking the execution status of the various processes and being able to restart (and preferably even debugging in case of problems during the execution of certain processes); controlling the state of the shared memory (for example by CRCs at the end of each segment) to avoid a problem of memory corruption and thus be able to react to rather by decreasing the impacts; for semaphore analysis for access to memory with the ability to unblock a situation of instability, etc. Modularity. Almost all known autopilot systems are based on closed architectures that can not be modified or modified by the manufacturer. The control system according to the invention has an architecture that allows the integration of new peripheral modules, or the replacement of modules by others. In this framework of modularity, it is important to mention the possibility of adding a communication space for the payload so that it can also use shared memory for exchanges between it and the other processes and the ground station ( in the case of drones). Modify a peripheral module. The modularity of the architecture of the present system makes it possible to change the functionalities of the system with the technological advances. For example, the arrival of the Galileo satellite positioning system will bring new positioning modules that are more precise and more efficient than those based on the GPS system. In this evolutionary framework, to replace an already integrated GPS module with a new Galileo positioning module, it will be enough to code a new interface process for this Galileo module while keeping the generic interface of all the processes, and the new Galileo module. can be taken into account in the system.

Certification Capacity. The organization of the system in different processes assists in the certification of the software because the different processes then have their own criticality levels to take place in a DAL compliant environment used in the DO-178. Also, this modularity makes it possible to make a decomposable analysis in the different subsystems to help the certification of each part. Flexibility. In contrast to closed systems, the design of the present system into different subsystems and processes makes it possible to change certain functionalities by others in case of particular need or evolution, while minimizing the potential impact on the entire system. . The common point to keep is the system interface through the shared memory, everything else is totally independent to each module and process. Performance. The modular architecture of the present control system makes it possible to gain efficiency in execution because only the necessary modules are those that are executed. Compared to thread architectures, this architecture allows you to run only the necessary codes, thus avoiding hundreds or thousands of unnecessary conditions typical in rate programming in single-threaded software. Features. In the context of avionics, the architecture of the present system may include in the basic configuration certain functionalities dedicated to autonomous systems in the airborne, such as: attitude determination process; - control process for flight management; - GPS position improvement process; 30 - net landing management system.

DESCRIPTION OF THE DRAWINGS Other features and features of the invention will become apparent from the detailed description of some advantageous embodiments presented below, by way of illustration, with reference to the accompanying drawings. These show: Fig.1: a schematic diagram of the present control system in a variant constituting and integrated into the avionics for drone; and Fig. 2: a diagram of the main configuration file structure and the process configuration file. In the following, we will give a more detailed explanation of the present control system, in an application to the field of aviation, and in which the modules and functions described are related to the control of an aircraft, in particular a drone. . However, it is clear that the operating principle is transposable to other control systems comprising a plurality of external peripheral modules providing information for conducting a mission, particularly in the automotive field. In the present text, the term "drone" designates any remotely piloted aircraft circulating without any person on board, and generally capable of loading a load. For certain proximity applications, the flight can be done in direct sight by a ground operator (the remote pilot), via the command and control system on the ground. For explorations out of sight, the drone preferably evolves in an "automatic" manner, that is to say that its evolution in flight has been programmed by any means whatsoever before the start of the flight, and / or is updated during the flight, and that all or part of the flight is carried out without direct intervention of the operator, except exception or mode of emergency control.

I. System Overview Figure 1 is a block diagram of the present control system 10. The reference sign 12 generally indicates a control unit forming the core of the system and comprising a computer with at least one processor 14, as well as a shared memory 16. A number of peripheral modules 181 to 18 are connected to the control unit 12. The control unit and the peripheral modules are generally in the form of electronic cards, the peripheral modules being connected to the control unit board. But peripheral modules 10 may be remotely connected to the board of the control unit, or integrated therein. The control unit 12 is programmed to conduct a mission. In general, the mission may consist of operating the vehicle, or the part of the vehicle with which it is associated, during the time of use of the vehicle. To carry out the mission, the control unit receives, processes and transmits data from and to the modules. In an avionic use for drone, the system 10 comprises a plurality of peripheral modules such as: IMU module 181: the inertial unit provides the attitude data of the aircraft 20 GPS module 182: provides the position information Actuator module (servo ) 185: control different actuators Module TM / TC 184: radio communication And other modules not yet shown in FIG. 1 such as: altimeter module, HRS module (route determination), Pitot module (25 speed measurement). air), Doppler Radar module (ground speed determination), tachometer, energy indicators, etc. In general, each module is in the form of an electronic card carrying the means (sensors, calculation means, etc.) required to implement the function or functions assigned to this module.

The calculator is and is configured as a partitioned system. It therefore comprises a shared memory 16, the partition being advantageously operated spatially and temporally. The principle of partitioning is well known in computing and conventionally applied in the field of avionics; this technology as such will not be described further. Thus all the appropriate partitioning technologies can be used. Each peripheral module is associated with a corresponding process 201 ... 20, which is linked to an own partition of the shared memory 16.

As used in this text, the term process refers generally and in its conventional sense to a program in progress. The control system implements a variety of processes, which it can initiate and terminate. Subsequently, the processes 20i associated with the peripheral modules are called the "application process" or simply "process". The PG manages the application processes 20; as well as other latent processes that can be started when needed. Note also the presence of the flight control process 205. This is generally a control process that: - receives as input the current status data of the platform (eg position, orientation etc. determined by the modules on board) and the desired state data (depending on the mission), - integrates the flight mode and the aerodynamics of the aircraft, and - interface with the actuators 185 to conduct the mission. The flight control process runs in a dedicated partition of the memory 16. The system may include several flight control programs, with a single flight control process in execution. This makes it possible to perform flights even in degraded cases where the aerodynamics have changed or when the actuators do not behave in a nominal way. It will be appreciated that the control system according to the present invention is particularly distinguished by the increased capability of a software layer of the so-called "guardian process" control unit 22 (also noted as PG), to react with the rest of the architecture. At the initialization of the system, the guardian process (whose execution starts as a priority) ingests one or more configuration files which define operating characteristics that may be envisaged during execution, such as for example: potential problems when communicating with the external device, behavior to take in case of system degradation, etc. In addition, this configuration file adds a description of the data structures used by the processes associated with the peripheral modules to enable the guardian process to verify the integrity of the data in memory during checks. This configuration file is fully compatible with the opening feature of the system because the end user can create these configuration files in a personal way respecting the adopted formalism. Figure 2 generally illustrates this configuration principle. A main configuration file 24 of the guardian process includes a definition of the various functions (peripheral module and associated applications), as well as the dedicated memory segments, etc. The guarding process also reads a configuration file 26 for the application process corresponding to each of the peripheral modules 18i. These configuration files 26 specify the modules, data structures, execution parameters, etc. The guardian process is designed to react in real time against any event that can affect or degrade the system in a global manner. The guarding process is advantageously programmed to fulfill one, preferably all, of the following functions: 1. Restart one or more processes in the event of an irretrievable failure or blockage. If a process no longer communicates with the guardian process, it no longer sends information about its execution status, and it no longer responds to calls from the guardian process. He can be killed and relaunched to ensure proper functioning. If, however, this process is no longer functioning in a nominal way, the guardian process may decide to operate without this process if it is not critical and / or to communicate to the control center this problem to analyze the possibilities of intervention. 2. Solving problems in execution state. The guarding process is programmed to control the robustness of the memory and other communication systems, so that it can react in the event of a malfunctioning process. For example (1), a process of a module belonging to the payload is corrupting the shared memory allocated to the payload. The guardian process will prevent access from this process to memory. Another case (2) may be the dysfunction of a critical process: in this context the guardian process will trigger the reset of the faulty process as well as the interfaces of this process to try to put the system back into a nominal operating condition. 3. Internal communication. The custodial process includes a communications component, to communicate and exchange information with the system's processes, allowing on the one hand to have a global vision of the execution of the system and also to be able to react in a local way if a problem concerns only one process or in general if several problems are cumulative on different processes. For example, assume that the inertial unit process can no longer communicate with the corresponding device module (ie, the inertial unit). The process communicates this problem to the guardian process, which can in turn restart the module, reconfigure the communication port, and so on. to try to solve the error. In advanced architectures, it is even possible to have a process dedicated to the electrical management of all modules and configured to turn off and on the modules.

Let us now suppose that at the same time that the inertial center process is communicating its problem, the application process of GPS reading also signals a communication problem with the GPS module, as well as the application process of reading the Pitot probe. the barometric altimeter, etc. In such a case, the guarding process will understand that it is no longer an isolated problem but a general operating problem and it will send a critical alert to the control unit to inform it of its condition. 4. Flight management. The guarding process is programmed to be able to modify the execution of the various processes in relation to the flight characteristics and / or system failures. All gradient flight possibilities are predetermined and therefore included in the configuration file. Here are some examples: If the GPS module breaks down beyond repair, the guarding process asks the navigation process to change the flight mode and the mission to proceed immediately with a new mission that will fly in circles around the point. current, and will be waiting for permission to land from the controller, once the recovery team has visited the site to retrieve the aircraft. It has been detected that the engine no longer operates, either by a motor revolution sensor (RPM), or by the observation that the commands sent to the engine to mount the thrust do not change the flight as expected. In this case, the gatekeeper process may require the flight control process to switch from the standard flight mode to a non-powered flight mode, and thus move the entire system to glider mode.

Other examples: 5. Generalized failure: 1) An X process alerts the guardian process (PG) of the failure of its associated peripheral module. 2) The PG requests the X process to restart and reset its device module. 3) Without having the notification of the good reinitialization of the module, another process Y announces that its associated peripheral module is in a state of malfunction. 4) The PG decides to make an explicit request to all other processes to check the operating status of their respective peripheral modules. 5) At this stage, the following cases may occur: a. All other peripheral modules are in good working order, so the PG decides, depending on whether or not mission-critical peripheral modules are critical for the mission, to announce a major or minor degradation state and return to the base (if possible) or continue the mission. b. The faulty peripheral modules are critical devices, but there are redundant modules in working order. At this level, and depending on the state of the mission, the PG may decide to continue the mission or return to the base. This decision can be made for example, depending on the percentage of mission already accomplished and what remains to be done. c. Other peripheral modules are also failing.

In this case, and with the remaining modules, the MP must make the decision to return to the base, make an emergency landing or remain in flight while waiting for the rescue team. In this situation, the PG must react according to the criticality and functionality of the peripheral modules. The inertial unit is an essential module for navigation; without it, it is impossible to fly. On the other hand, other modules such as GPS, pitot probe or barometric altimeter are not essential. 6. Failure of a non-critical and non-redundant module: 1) For example, consider the case of the barometric altimeter module. Three possibilities can appear: a. The application process associated with the altimeter is corrupting the memory with erroneous information and, after the process is reset, there is no improvement. b. The process announces that its module is faulty and that it can not obtain correct information. c. No more information from the altimeter process, without successful resolution from the MP. 2) The PG asks the GPS process to store the value of the altitude obtained by the satellites. 3) The PG requests the interface process with the inertial unit to add a height variation estimate and adjust it with that produced by the GPS. 4) The PG announces to the flight control process that the altitude is no longer as reliable as before (decrease in reliability / degraded mode) and that it must take a much more conservative approach to elevator management (pitch management). 5) Depending on the state of the mission, the PG decides to cancel the mission and return to base or continue.

A similar situation can also occur with other peripheral modules, for example the Pitot probe: it is very important for a controlled flight, but it is quite possible to do without it by adopting a very conservative piloting. 7. Failure of a critical module and with redundancy: 1) Several possibilities are to be analyzed in the situation of failure of a critical module, for example, the inertial unit (in this example, there is at least at least one three modules IMU inertial unit). at. In general, these situations lead to a state where the information associated with the IMU1 is not consistent with that of the IMU2. b. If there are more than 2 IMUs, the PG does an analysis of the data of all the inertial units and it asks the process of the incoherent IMU to solve the problem or to stop its execution (in case of impossibility of resolution ). c. The PG goes into a degraded state, but it continues the mission if there are still at least two redundant means. 2) When there is no consistency between at least two IMUs, the procedure to find out which module is faulty is more complex: a. The MP asks the attitude estimation process to give an attitude estimate based on the latest historical HRS GPS data and possibly altitude. b. The PG makes a comparison of this estimate of pitch, yaw and roll with those obtained through data from inertial units. c. The yaw of GPS is also compared with that obtained through inertial data. d. If an inertial unit is clearly defective (level of digression between the measurements given by the IMU and the estimated values) in all the comparisons, the PG asks the process to resolve the malfunction state or to stop. e. If two remaining IMU modules are in a very similar state of inconsistency (similar values of digression compared to the estimated values), or are not at all similar, the PG goes into emergency state and commands a landing of with the estimates given by the least weak IMU. 8. Interpretation and investigation of the error when there is a fault in a non-redundant critical module, for example the motor. 1) The PG receives from the engine management process a malfunction in the engine or for example in the tachometer module. 2) If the system has other modules related to the motor, for example a current generator driven by the motor, the PG can ask these modules to return the value of the electricity produced, which is a function of the motor speed. . 3) If the information is positive and the generator coupled to the motor is still producing electricity, the PG informs the engine manager of the malfunction of the lap counting device. Then, the PG announces this malfunction to the steering control system and requests a more conservative control during the engine control, because the response of the latter can no longer be verified with the same precision. 4) If the power management module of the generator driven by the engine does not detect any electricity produced, the PG may request a troubleshooting of the situation with the following: a. The PG checks that no maneuver is in progress (verification of the information of the attitude in flight), so the attitude is flat. b. The PG checks the condition of the flight management surfaces (elevators, ailerons, etc.) and puts them in a state of rest. c. The PG requests the inertial unit process to check for instantaneous acceleration. d. The PG asks the control process to make an engine acceleration. e. The PG analyzes the results of the modules of inertial units to check if the accelerators show an acceleration in the direction of movement, following the request for acceleration. 5) If accelerations have been detected, several non-critical sensor modules are in a state of failure which leads to the described state of a generalized failure where the faulty devices must be isolated to make the correct decisions. 6) If no acceleration has been detected, the engine fails and the PG requests the control system to go into glider mode for an emergency landing without an engine.

He. Example of an avionics system with its modules The control system is intended to constitute and configure a part of an avionics system for an aircraft, particularly for a drone. The architecture of this system is simple and efficient in design. The custodial process ensures that the system functions properly and implements, as far as possible, a strategy for providing surrogate data when a peripheral module fails. In a variant, in the context of the architecture illustrated in FIG. 1, the system comprises, in addition to the central unit 12, the following peripheral modules: IMU, GPS, HRS, altimeter, pitot, Doppler radar, communication, tachometer, indicators of energy, servo-control. Each of these modules is associated with a respective application process which is advantageously operated in a respective partition of the shared memory 16. Table I summarizes, for each peripheral module, the main function, designating the objective of this function ( Name column) and the determination principle (method column). In the case of the IMU inertial unit, its main objective is to determine the attitude of the aircraft, and this determination is made by means of dedicated sensors (generally accelerometers and 3-axis gyroscope, in particular of the MEMS type ).

A portion of these peripheral modules are configured for at least one secondary function, which provides information of the same nature as another of the peripheral modules (secondary function (1) and (2)). Thus, in the case of the IMU, the latter is configured to provide one or two of the following secondary functions: 1. position determination: the acceleration sensors of the IMU module are used according to a temporal integration approach of the sensors to provide position data. Although the accuracy of the positioning will be lower than that of a GPS module, it is sufficient to fly in a so-called degraded mode. 2. Attitude Determination: The acceleration sensors of the IMU are used using a temporal integration approach of the sensors to provide attitude data of the aircraft, typically pitch, roll and yaw.

Therefore, when the IMU is further provided for these two secondary functions, the PG knows that it can, in case of failure of the GPS module, use in substitution positioning data provided by the IMU module, or in case of HRS module failure, substitute route data provided by the IMU module. Thus, in the context of an avionics system, the IMU, GPS, HRS, altimeter, pitot and Doppler radar modules are advantageously configured to include at least one secondary function listed in Table I, so that this secondary function can be used by the PG when needed.

It is clear that the system is open to other modules, for which we can also define a main function and a secondary function in backup of another peripheral module. This example does not describe redundant modules (such as two IMUs, one backup of the other). But it is understood that the present system is also open to this type of configuration where there are several types of similar modules to provide the same main function, redundant between them. Table II describes the various functions that the flight system needs to fly the aircraft. For each function, the main module 20 providing information in the nominal operating mode (main module) and, if appropriate, a secondary module (1) capable of supplying substitution data for the same function in a degraded mode of operation are defined. level 1, and possibly a second secondary module (2) able to provide substitution data for the same function in a level 2 degraded mode. Description of the Configuration Files In order to implement the strategy presented above in which peripheral modules of different natures can mutually serve as backup, configuration files are used for the PG and for the modules, these files providing the functions and exchanges. These configuration files preferably use XML technology for coding information. 1. Main configuration file - dedicated to the PG The main configuration file is used by the PG and lists the functionalities required for flight management. For each function, we define: - the module providing the information required for a main function. This is the function used in the nominal operating mode (indicated as "prime"). the module or modules that can provide replacement data for certain functions, in a degraded operating mode. The modules used for backup are classified in order of importance (indicated Degr1, degr2, etc. - the most efficient being Degr1). - the criticality level of the function in the system. - and the memory segment allocated to the application process The structure of the configuration file is described below in IV.1, and incorporates the functionalities according to Tables I and II. 2. Description of the definition file of all the modules: In addition to the main configuration file, the PG uses a "modules" file, which defines the different peripheral modules and for each of them: the main function; or the functions in a state of degradation, that is to say, functions that the equipment is capable of providing but in a quality and precision lower than those of the module (s) dedicated to this / these function (s) ). The structure of the "modules" file is described in IV.2 below. According to Table II, this file defines that the main function (nominal mode) of the IMU is to provide the attitude information, but also delivers, in accordance with the secondary functions in degraded mode, position and altitude information.

It will be appreciated in particular that gradient modes of operation can be declared in case the main mode can no longer be applied in a nominal fashion. In the example given, in the case of the actuators, there is a defined nominal control mode, but two other modes that can be launched in case of malfunction in the management of the pitch information and which will allow to adapt the mode of behavior of the system to the anomalies found. Therefore, the guardian process will have the possibility to start the execution of these modes in substitution of the nominal mode if the events arrived specify it. 3. Description of the files per module: For each of the peripheral modules to be used in the system, an individual module file is still created. As already indicated, the functions listed in Table II and required for flight management are given through an application process which is associated, in the nominal mode, with a peripheral module having a main function corresponding to this application process. If there are two redundant peripheral modules for the same function, they are managed by the same application process.

The structure of the module application file that is used by an application process linked to a peripheral module comprises at least part of the following sections: - Name of the file that will execute for accessing the information (FILE section). - Log file name (Logfile item). - Declaration of redundancy if there is any, and if so, what type, what is the redundant program, etc. (Redundancy section). - Definition of the global functions of the subsystem (Function heading) in nominal and in gradient, as well as the names of the routines that execute the 30 instructions and the names of the variables expected at runtime, with the frequency of execution in hertz . - Declaration of actions in the case of communication problems (Communication Error section), on the one hand between the process and the module (number of times of restart, if we can restart the interface or not, etc.) and between the guardian process and this specific process, as well as the waiting time before initiating a no-call alarm, as well as the number of acceptable alarms before triggering the process recovery procedure. - Definition of the type of communication interface with the dedicated module.

Take the example given above at 1-7) of an IMU inertial unit. Each device must have an associated process that accesses its resources. In case of hot redundancy, two processes can be started on two different equipments, but only one has the hand to provide the data of the inertial unit; this possibility is detailed in the sample file. In this case, it is necessary to indicate to the process guardian who is (are) the redundant process (es) to allow him to react in case of anomaly. If the redundancy is cold, you must also indicate in the other file of the redundant process that you should not start the execution to avoid consuming machine time without needing. This case may occur in telemetry and remote control management, because the start of the task is fast enough to give a sense of transparency in the management of redundancy.

One can have the case of a process that accesses two modules. In this case, we will specify the access interfaces and the expected behavior for each device. Each descriptive file of each process contains the following elements: - Name of the file that will execute for accessing the information. - Name of the log file. - Declaration of redundancy if there is one, and if so which type, what is the redundant process, etc. - Definition of the global functions of the subsystem in nominal and degraded mode, as well as the name of the routine of the program executing the instructions, the names of values expected at runtime and the expected frequency of execution in hertz ( number of times per second). - Declaration of actions in the case of communication problems, on the one hand between the process and its device (number of times of restart, if we can restart the interface or not, etc.) and between the process of guardian and this specific process, as well as the time that can be expected before initiating a non-communication alarm and how many alarms must be accumulated before triggering the process recovery procedure. - Definition of the type of communication interface with the dedicated device.

IV. Examples of file structures IV.1 General configuration file (dedicated to the Guardian Process) The file is broken down into different parts that define the rules of behavior for all cases considered in advance. <Function Description> <Attitude Determination> <Prime> <IMU> </ Prime> <Degr1> <GPS> </ Degr1> <Degr2> <HRS> </ Degr2> <Degr3> <Altimeter> </ Degr3> <CRIT = LEVEL1 /> <Memory Segment = 'ATTDMS' /> </ Attitude Determination> <Heading Determination> <Prime> <HRS> </ Prime> <Degr1> <GPS> </ Degr1> <Degr2> <IMU> </ Degr2> <Memory Segment = 'HEADMS' /> <CRIT = LEVEL2 /> </ Heading Determination> <Position Determination> <Prime> <GPS> </ Prime> <Degr1> <IMU> </ Degr1> <Memory Segment = 'POSDMS' /> <CRIT = LEVEL2 /> </ Position Determination> <Altitude Determination> <Prime> <Altimeter> </ Prime> <Degr1> <GPS> </ Degr1> <Degr2> <IMU> </ Degr2> <Memory Segment = 'ALTDMS' /> <CRIT = LEVEL2 /> </ Altitude Determination> <Air Speed Measurement> <Prime> <Pitot> </ Prime> <Memory Segment = 'ASPMMS' /> <CRIT = LEVEL3 /> </ Air Speed Measurement> <Ground Speed> <Prime> <RADAR Doppler> </ Prime> <Degr1> <GPS> </ Degr1> <Degr2> <IMU> </ Degr2> <Memory Segment = 'GRSPMS' /> <CRIT = LEVEL3 /> </ Ground Speed> <Throttle Management> <Prime> <Tachometer> </ Prime> <Degr1> <Energy Meter> </ Degr1> <Memory Segment = "PRMGMS" /> <CRIT = LEVEL2 /> </ Throttle Management> <Energy Management> <Prime> <Energy Meter> </ Prime> <CRIT = LEVEL3 /> </ Energy Management> <Ground Station Communications <Prime> <Comm Device> </ Prime> <Degr1> <Ext Lights> </ Degrl> <Memory Segment = 'SCOMMS' /> <CRIT = LEVEL2 /> </ Ground Communications Station> <Control Management> <Prime > <Actuators> </ Prime> <Memory Segment = 'CIRLMS' /> <CRIT = LEVEL1 /> </ Control Management> </ Function Description> IV.2 Description of the modules file <Subsystem Description> <IMU> <Prime> <Attitude Determination = '> </ Prime> <Degr> <Position Determination> </ Degr> <Degr> <Altitude Determination> </ IMG> </ Prime> <Position> </ Prime> <Position> <Degr> <Altitude Determination> </ Degr> <Degr> <Ground Speed> <Degr /> <Degr> <Heading Determination> </ Degr> <Degr> <Attitude Determination> </ Degr> </ GPS> <HRS > <Prime> <Heading Determination> </ Prime> <Degr> <Attitude Determination> </ HRS> <Altimeter> <Prime> <Altitude Determination> </ Prime> <Degr> <Attitude Deter Mining> </ Degr> </ Altimeter> <Pitot> <Prime> <Air Speed Measurement> </ Prime> <Degr> <Altitude Determination> </ Degr> </ Pitot> <RADAR Doppler> <Prime> <Ground Speed > </ Prime /> <Degr> <Altitude Determination> </ Degr> </ Doppler RADAR> <Comm Device> <Prime> <Ground Station Communications> </ Prime> </ Comm Device> <Tachometer> <Prime> < Throttle Management> </ Prime> <FILE = '/ Tachometer.exe' /> </ Tachometer> <Energy Meter> <Prime> <Energy Management> </ Prime> <Degr> <Throttle Management> </ Degr> </ Energy Meter> <Actuators> <Prime> <Control Management> </ Prime> <Degr> <Conservative Pitch Control> </ Degr> <Specific Landing> </ Degr> </ Actuators> </ Subsystem Description> IV .3 Configuration file dedicated to each peripheral module: <IMUl> <FILE '/IMU.exe' /> <LogFile 'IMU.log /> <Startup Init YES /> <Redundancy> <TypeRedondancy HOT /> <Redondand Rol Prime / > <Redundant Torque IMU2 /> </ Redondancy> <Function> <Attitude Determination> <Name 'AttDetermination' /> <Values> <pitch /> <roll /> </ Values> <Frequency 100 /> <Po Determination> <Name = 'PosIntegration' /> <Values> <longitude /> <latitude /> <ground speed /> </ Values> <Frequency 2 /> </ Position Determination> <Altitude Determination> <Name = 'AltCalculation '/> <Values> <altitude /> <vertical speed /> </ Values> <Frequency 2 /> </ Altitude Determination> </ Function> <Communication Error> <Device Error> <Retries 3 /> <mit Port YES /> <mit Memory NO /> </ Device Error> <Watchdog '50ms' /> <Process Error> <Retries comm 3> <Delay Retries 20ms /> <mit Process YES /> </ Process Error> </ Communication Error > <Device Interface> <Type 'UART1' /> <Speed 9600 /> <Characteristics 8N1 /> </ Device Interface> </ IMU1> 15

Claims (16)

REVENDICATIONS1. An onboard control system of a vehicle comprising: a control unit (12) including a computer; a plurality of peripheral modules (18;) each performing a particular principal function, each peripheral module comprising at least one dedicated sensor providing the measurements to fulfill its main function; the control unit (12) being configured to receive information from the peripheral modules (18;) and to conduct a mission based on this information; characterized in that at least one of the peripheral modules (181) is configured to, by means of its at least one sensor, perform its main function and, on request, perform a predetermined secondary function corresponding to the main function of another module device (182) of the system; and the control unit (12) is configured to implement a guarding process (PG) for: checking the operating status of each of the peripheral modules and, in the event of a peripheral module failure , evaluate the possibility of performing the mission in a degraded mode, in particular by activating a secondary function in a non-defective peripheral module, to be used by the control module in substitution of the main function data of the defective peripheral module. 2. An onboard control system according to claim 1, wherein, when no non-faulty peripheral module having a secondary function capable of replacing the defective peripheral module is found, the guardian process evaluates the possibility of continuing the mission. with the complete loss of the defective peripheral module, and in particular, if the mission can not be continued without said defective device module, the guarding process triggers an emergency shutdown procedure. An onboard control system according to claim 2, wherein, if the mission can be continued without said defective peripheral module, in a degraded control mode, then the guarding process invites the user to decide whether to continue the mission or of its end. An onboard control system according to any one of the preceding claims, wherein as soon as an inconsistency of a peripheral module is detected, the guarding process triggers an error situation recovery routine including preferably at least one of the following actions: restarting the sensor or the peripheral module, resetting the communication with the peripheral module, requesting the other peripheral modules their communication status. An onboard control system according to any one of the preceding claims, wherein a peripheral module is configured to perform at least one other secondary function corresponding to the primary function of another peripheral module of the system. An onboard control system according to any one of the preceding claims, wherein an application process (20;) corresponding to each peripheral module (181) is executed in a dedicated partition of the control module memory (16). 7. Embedded control system according to any one of the preceding claims, wherein each peripheral module (18;) is in the form of an electronic card. 25 8. Embedded control system according to any one of the preceding claims, comprising at least a portion of the following peripheral modules: IMU, GPS, HRS, altimeter, pitot, Doppler radar, and wherein each of these peripheral modules is configured to operate. a main function and at least one secondary function. 30 An onboard control system according to any one of the preceding claims, wherein: the IMU module is configured to provide, as its main function, attitude data, and as its secondary function data position and / or altitude; and / or the GPS module is configured to provide, as its main function, position data, and as its secondary function data altitude, ground speed, route and / or attitude; and / or the HRS module is configured to provide, as its main function, route data, and as its secondary function attitude data; and / or the Altimeter module is configured to provide, as its main function, altitude data, and as its secondary function vertical velocity and / or pitch data; and / or the pitot module is configured to provide, as its main function, air velocity data, and as its secondary function altitude data; and / or the Doppler Radar module is configured to provide, as its main function, ground speed data, and as its secondary function altitude and / or vertical speed data. 10. Embedded control system according to any one of the preceding claims, wherein a main configuration file is associated with the guardian process, which file defines the list of functions required for the mission, and defines for at least part of these functions: the peripheral module providing the information required for the function in nominal mode; the peripheral module or modules capable of providing replacement information in degraded mode; and preferably the criticality level and / or the memory segment allocated to the application process. 11. Embedded control system according to any one of the preceding claims, comprising a module file which defines the different peripheral modules and for each of them: the main function and the substitution function or functions in degraded mode. An onboard control system as claimed in any one of the preceding claims, wherein the application process associated with a peripheral module uses a file which defines: global functions of said peripheral module in nominal and degraded mode, actions in the communication problems, between the process and the module, and between the guardian process and the application process. An onboard control system according to any one of the preceding claims, wherein the control unit implements a flight control process. 14. Avionics system, in particular for drones or aircraft, comprising a control system according to any one of the preceding claims. 15. Onboard control system of a motor vehicle comprising a control system according to any one of claims 1 to 12. 16. A method of operating an on-board control system for a vehicle, said control system comprising a control module receiving, for the fulfillment of a mission, information from a plurality of peripheral modules each performing a main function determined, each peripheral module having at least one dedicated sensor providing measurements to fulfill its main function, said method being characterized in that it implements a guarding process whose function is: to check the operating status of each of the peripheral modules and, in the event of a peripheral module failure, evaluate the possibility of carrying out the mission in a degraded mode, in particular by activating a secondary function in a non-defective peripheral module, to be used by the module of command replacing the main function data of the defective peripheral module.