Calculateur CDVE

V.2.1.1. Architecture matérielle et logicielle

L’architecture matérielle et logicielle des calculateurs dans l’architecture à priorités est identique à celle de l’architecture à vote massif (cf. chapitre III, section III.2.1.1.).

V.2.1.2. Description fonctionnelle 1) Interface système

Pour fonctionner, les calculateurs commandes de vol produisent et consomment des flux de données. Ces flux sont reçus et transmis via le même réseau de communication dans une ou plusieurs trames de données, selon les technologies et les protocoles de communication retenus.

Certaines informations peuvent être envoyées à des cycles différents (ordres et validations). Ces calculateurs ont également besoin d’une alimentation électrique. Celle-ci est fournie par l’un des deux systèmes électriques de l’avion, en fonction de la localisation géographique du calculateur (côté droit ou côté gauche). Le Tableau V.2 décrit ces flux de données.

Flux de données

Description Type Flux entrant

(source)

Flux sortant (destinataire) Paramètres lois Les fonctions lois de pilotage consomment des

paramètres « lois » : position envoyée par les organes de commande en cockpit, paramètres anémo-inertiels de l’avion, …

Système avion

cockpit, capteurs, … Ordres Maître Le calculateur maître calcule les lois de pilotage

et l’ensemble des ordres gouverne pour tous les actionneurs.

Trame Ordre

FCRMs

Validations Le calculateur valideur compare son ordre avec les ordres des autres calculateurs maîtres pour lesquels il est valideur et il transmet le résultat (validation ou non) aux actionneurs concernés.

Trame Validation

FCRMs

Retour_FCRM Le calculateur reçoit des retours de toutes les unités COM et MON de tous les actionneurs dont il est maître. Les retours donnent la validité de son statut de maître par rapport aux résultats de choix des priorités fait par chaque FCRM.

Trame FCRM

FCRMs

Tableau V.2 - Flux de données entrants et sortants des calculateurs

Plusieurs remarques :

• Vu les différences entres les deux architectures, on ne retrouve pas tous les mêmes flux que pour les calculateurs de la première architecture (à vote massif).

• Les trames Trame_Ordre et Trame_FCRM ont un format semblable à celui défini pour l’architecture à vote massif (cf. III.2.2.2.a). Et nous n’avons pas repris ici les flux de la gestion électrique des FCRM qu’assurent les calculateurs.

110 Chapitre V - Architecture à priorités

• Les Trame_Ordre et Trame_Validation, issues de chaque calculateur, ne vont pas directement aux FCRM : elles sont en fait d’abord regroupées ou « concaténées » au niveau du réseau pour simplifier les traitements au niveau des FCRM. Ce principe de concaténation des trames a déjà été évoqué pour l’architecture à vote massif.

Au final, nous ne précisons ici que les Trame_Validation : chaque calculateur compare ses ordres en loi normale, et en loi directe, à ceux des ordres des autres calculateurs qu’il surveille en tant que valideur. Pour simplifier les traitements au niveau des FCRM, on considère un format unique à tous les calculateurs pour les trames de validation avec le format et les valeurs booléennes suivantes :

Adresse destinataire Adresse source Type de la trame Validité loi N FCCP1 Validité loi D FCCP1 Validité loi N FCCP2 Validité loi D FCCP2 Validité loi D FCCS1 Validité loi N FCCP3 Validité loi D FCCP3 Validité loi N FCCP4 Validité loi D FCCP4 Validité loi D FCCS2

− la valeur 11 : je valide l’ordre − la valeur 01 : je ne valide pas l’ordre

− la valeur 00 : je ne suis pas valideur de l’ordre

Voici un exemple de Trame_Validation envoyée par le calculateur FCCP2 dans son rôle de valideur en loi normale pour les calculateurs FCCP1 et FCCP3, et en loi directe pour le calculateur FCCS1 :

FCRM FCCP2 Trame de

validation

11 01 00 00 11 11 00 00 00 00

2) Architecture fonctionnelle de base

Le logiciel fonctionnel de chacun de ces calculateurs peut schématiquement être réparti en trois catégories (comme l’illustre la Figure V.2) :

a) le calcul des lois de pilotage pour déterminer les ordres en tant que calculateur maître, b) le calcul des fonctions de validation pour déterminer les validations en tant que

calculateur valideur (par simple comparaison), c) les surveillances (cf. chapitre III, section 2.1.2.3).

Un point capital à relever est que le calcul des validations dans chaque calculateur se fait par rapport aux ordres du cycle précédent. En effet, à chaque cycle de calcul, chaque calculateur transmet ses ordres (loi normale et loi directe) sur le réseau de communication. Les ordres d’un même cycle de tous le calculateurs seront regroupés dans une seule trame au niveau de réseau qui la transmet ensuite vers les actionneurs et vers les calculateurs. Ainsi, un calculateur valideur calcule des validations pour des ordres (l’ordre du valideur et les ordres des autres calculateurs) d’une même trame et qui ont été calculés dans un même cycle.

Calcul loi de pilotage Calculateur Retours FCRMs Surveillances applicatives Surveillances matérielles

détecteur Ordres Maître

Calcul des validations

Ordres calculateurs Validations

V.2 Description détaillée des différents composants de l’architecture 111

3) Principe de fonctionnement et logiques spécifiques (niveau calculateur)

Chaque calculateur émet systématiquement ses ordres vers les actionneurs dont il est maître et émet des validités vers chaque calculateur dont il est valideur.

La définition (ou le choix) de « quel calculateur joue quel rôle (maître ou valideur) à quel moment » est faite de manière statique, donc prédéfinie. Par la suite, nous considérons la configuration nominale du Tableau V.3 pour les calculateurs valideurs. Chaque ligne indique pour un calculateur, son type de logiciel et de matériel, puis quel sera son ou ses calculateurs valideurs. Par exemple, pour le calculateur FCCP1, ses valideurs sont FCCP2 ou FCCP4, ou FCCP3 en cas de reconfiguration de ce dernier suite à la perte de FCCP4 et FCCP2.

Rappelons que l’architecture est composée de 6 calculateurs « simplex » dont 4 unités avec un matériel H1 exécutant des fonctions évoluées (FCCP – primaire) en loi normale et des fonctions simples en loi directe, et 2 unités avec un matériel H2 exécutant des fonctions simples (FCCS - secondaire) en la loi directe seulement. Et on considère aussi 3 logiciels différents pour l’ensemble des calculateurs : 2 variantes dissimilaires pour le logiciel des lois normale et directe des calculateurs primaires (logiciel A et logiciel B), et une seule variante pour le logiciel de la loi directe des calculateurs secondaires (logiciel C).

Calculateur Maître Logiciel Matériel Calculateur valideur FCCP1 logiciel A H1 FCCP2 en loi normale ou

FCCP4 en loi normale ou

FCCP3 en loi normale si reconfiguration FCCP3 logiciel B H1 FCCP2 en loi normale ou

FCCP4 en loi normale

FCCP2 logiciel C H1 FCCP4 en loi normale si reconfiguration FCCS1 logiciel C H2 FCCP2 en loi directe ou

FCCP1 en loi directe ou FCCS2 en loi directe FCCS2 logiciel C H2 FCCP4 en loi directe ou

FCCP3 en loi directe ou FCCS1 en loi directe

Tableau V.3 - Configuration nominale de calculateurs valideurs

V.2.2

Les électroniques locales FCRM

V.2.2.1. Architecture matérielle et logicielle

Comme pour l’architecture à vote massif, dans l’architecture à priorités, chaque actionneur est équipé d’au moins une électronique locale avec des capacités pour : communiquer sur le réseau numérique, réaliser des opérations de choix et piloter les actionneurs. Et comme pour l’architecture à vote massif, un FCRM est composé d’une voie COM et d’une voie MON.

V.2.2.2. Description fonctionnelle 1) Interface système

Les deux voies COM et MON de chaque actionneur implémentent la même logique de priorité. Les logiques de priorité tiennent compte de la dégradation des lois (passage de loi normale en loi directe). Les électroniques locales de chaque actionneur produisent et consomment les flux de données décrits dans le Tableau V.4.

112 Chapitre V - Architecture à priorités

Ces flux sont reçus et transmis via le même réseau de communication (dans une ou plusieurs trames de données) selon les protocoles de communication retenus.

Flux de données Description Type Flux entrant

(source)

Flux sortant (destinataire) Trame_réseau_maître Ordres des calculateurs maîtres. Trame_Réseau_

Maître

Calculateurs Ordres_valideur Validation des calculateurs

valideurs.

Trame_Réseau_ Validation

Calculateurs Ordre_actionneur Le FCRM (voie COM) réalise

l’asservissement local de l’actionneur.

Actionneurs

Retour_FCRM Résultat du vote et les

acquittements FCRM (celui du COM et celui du MON) vers les calculateurs.

Trame FCRM Calculateurs

Tableau V.4 - Flux de données d’un FCRM

On se limitera ici à évoquer deux aspects significatifs révélés par ce tableau : la

Trame_Réseau_Maître (respectivement Trame_Réseau_Validation) reçue par chaque

FCRM est une trame unique qui est le résultat de la concaténation par le réseau des

Trame_Ordre (respectivement Trame_Validation) du Tableau V.3 issues de chacun des

calculateurs maîtres (respectivement valideurs).

2) Architecture fonctionnelle de base

Les ordres et les validations sont calculés par tous les calculateurs. Le choix de l’ordre à appliquer à l’actionneur est le résultat d’un vote (portant sur tous les ordres reçus) réalisé par les électroniques locales. Dit autrement, les électroniques locales « sélectionnent » les ordres qui seront appliqués par les voies COM des électroniques locales associées à chaque actionneur. La voie MON surveille la voie COM et a le pouvoir de désactiver le COM et/ou l’actionneur en cas de désaccord.

Le logiciel fonctionnel des FCRM peut schématiquement être réparti en deux catégories : 1) logique de priorités,

2) logique de validation.

Le modèle de la Figure V.3 présente le schéma fonctionnel de la voie COM.

Logiques Priorités

FCRM

Validation

Ordre actionneur

Retours calculateurs Ordres des maîtres Validités correspondantes

Logiques Priorités

FCRM

Validation

Ordre actionneur

Retours calculateurs Ordres des maîtres Validités correspondantes

Figure V.3 - Schéma fonctionnel de la voie COM d’un FCRM

La différence avec l’architecture fonctionnelle d’un FCRM dans l’architecture à vote massif est une des plus significatives entre les deux architectures. Il s’agit donc là d’un des aspects importants au niveau des modélisations faites en vue des simulations de validation, en particulier au niveau des simulations sur la robustesse.

V.2 Description détaillée des différents composants de l’architecture 113

Or, comme nous ne présenterons pas, pour cette architecture à priorités, toutes les modélisations et simulations réalisées dans un chapitre spécifique (contrairement à ce qui avait été fait pour l’architecture à vote massif), nous présentons ici directement, sur la Figure V.4, le modèle Simulink établi pour un FRCM dans cette architecture à priorités.

Figure V.4 - Modèle Simulink pour un FCRM

3) Principe de fonctionnement et logiques spécifiques (niveau FCRM)

Comparativement à l’architecture à vote massif, le traitement FCRM est très simple. Il suffit de lire l’ordre du calculateur FCCP1 (calculateur maître qui possède la priorité la plus élevée) de la trame (Trame_Réseau_Maître) et de vérifier sa validité sur les champs (Validité Loi N FCCP1) des calculateurs valideurs selon le Tableau V.1. Dans le cas où tous les champs (Validité Loi N FCCP1) de tous les calculateurs valideurs sont à (01), le FCRM doit refaire la même chose avec l’ordre du calculateur FCCP3 selon le Tableau V.3. Le passage d’un maître à un autre doit être échangé entre les deux voies COM et MON du FCRM.

114 Chapitre V - Architecture à priorités