Projets Avioniques

Transcription

Projets Avioniques

Projets Avioniques
Mise sur pied d’un banc d’essai pour l’évaluation, le développement, le prototypage, la simulation et la validation de technologies
avioniques
NUMERICA TECHNOLOGIES INC.
3420 rue Lacoste
Québec, QC G2E 4P8 Canada
Responsable du projet: David Prévost
Numéro de contrat : W7701-053273/001/QCL
Autorité scientifique chargée du contrat:: Éric Dumais
Tél: 418-844-4000 ext. 4464
L’entrepreneur est entièrement responsable de la validité du contenu scientifique et technique du présent rapport
de contrat et celui-ci n’a pas nécessairement reçu l’approbation ou l’appui de R & D pour la défense Canada.
R&D pour la Defense Canada – Valcartier
Rapport de contrat
DRDC Valcartier CR 2007-584
21 Septembre 2007
Projets Avioniques
Mise sur pied d’un banc d’essai pour l’évaluation, le
développement, le prototypage, la simulation et la validation de
technologies avioniques
RAPPORT DE CONTRACTEUR
PRÉPARÉ POUR
DEFENCE R&D CANADA - VALCARTIER
R&D POUR LA DÉFENSE CANADA - VALCARTIER
QUEBEC, QC G3J 1X5
CANADA
Numéro de contrat : W7701-053273/001/QCL
Autorité scientifique : Éric Dumais
Tél: 418-844-4000 ext. 4464
PAR
David Prévost
3420 rue Lacoste
21 Septembre 2007
L’entrepreneur est entièrement responsable de la validité scientifique ou technique de ce
rapport de contrat, et le contenu de ce rapport n’est pas nécessairement approuvé ni
entériné pas R et D pour la défense Canada.
CR 2007 - 584
Abstract
The main objective of this project was to implement and configure hardware using
military communication to eventually run several simulations communicating each
other with as example the MIL-STD-1553 protocol. The system was supposed to
include among other systems a CF-18 simulator called ASPB, a Multipurpose
computer unit (MPCU). An experimentation plan needed to be proposed and
implemented to verify the system functionality. However, the ASPB incompatibility
with the MIL-STD-1553 protocol and the MPCU card purchase delay has resolved in
the incapability to install the laboratory system. Consequently, the system validity
wasn’t proved. Alternatively, other system’s implementations were searched and
documented.
Résumé
L’objectif du projet était d’installer et de configurer un système matériel de laboratoire
utilisant des protocoles militaires, permettant ainsi la simulation de plusieurs scénarios
communiquant avec par exemple, le protocole MIL-STD-1553. Le système devait
comprendre entre autres un simulateur de CF-18 nommée ASPB et un Multipurpose
computer unit (MPCU). Un plan d’expérience devait être proposé et implanté pour
démontrer le fonctionnement du système. Par contre, l’incompatibilité de l'ASPB avec
le MIL-STD-1553 et le retard prolongé pour l’obtention d’une pièce du MPCU n’ont
pas permis de monter les composantes matérielles et, donc aucun plan d’expérience
n’a pu démontrer le fonctionnement du laboratoire. Compte tenu de ces problèmes,
d’autres implantations du système ont été explorées et sont présentées dans ce rapport.
CR 2007 - 584
i
Page intentionnellement laissée en blanc.
ii
CR 2007 - 584
Executive summary
DRDC Valcartier is proposing to further develop its expertise in development and
testing of avionics systems by investigating tools and techniques for analyzing
software interaction with its physical environment. This include: 1) Stimulating
software at application program interface level, 2) Emulating other systems that
interact with the avionics on the avionics bus or by discrete input-output signals, 3)
Performing signal injection in the sensors signal processing units.
Canadian Forces has established a sophisticated set of software development tools and
test facilities that has increased the productivity, quality and reliability of the
Operational Flight Programs (OFP) developed for the CF-18. One of these tools is the
CF-18 Avionics Simulation & Prototyping Bench (ASPB). The ASPB is a PC based
simulator that uses emulators and models to produce a low cost virtual CF-18. This
asset significantly reduces the need for real aircraft avionics. Fewer test stations with
hardware in the loop are required, thus reducing maintenance costs and improving
reliability. Because the ASPB runs the actual aircraft software (MC, SMS, CSC &
MDG), the system stays ahead of the fleet when new OFPs are released making it ideal
for pilot familiarization and training.
DRDC desire to use the ASPB to investigate implementation feasibility of robust CF18 laser designation techniques against counter-measures. These techniques are
currently in development in project 13ev "Improved smart-weapons tracking and
discrimination in a countermeasure rich environment".
Currently, the CF-18’s are undergoing an extensive modernization project that
includes new and upgraded avionics and weapon systems. However, with rapidly
evolving technology, even the modernized CF-18 will soon suffer capability
constraints and obsolescence issues. The Canadian Forces have tasked the System
Engineering Support Contract (SESC) to investigate the applicability of advanced
concepts and emerging technologies for the CF-18 under the “Advanced Concepts &
Technologies” (ACT) initiative. SESC is developing the new Multi-Purpose
Computing Unit (MPCU) tool. The MPCU is a real-time avionic prototyping platform
used to investigate new concepts & technologies, for example: high-speed data
transfer, future processing power capability, voice activated commands (speech
recognition) and sensor imagery transfer over MIDS.
DRDC desire to use the MPCU to evaluate new concepts currently in development in
project 13ew "Network Enabled Weapons for Tomorrow’s Precision Strike". An
objective of this project is to capture operational and technological requirements for
network-enabled precision strike, define and evaluate the solution space of viable
precision weapon concepts and component technologies, and provide substantiated
recommendations for the most promising options. To achieve this, DRDC wants to
investigate military communications technologies using real-time avionic prototyping
platform.
CR 2007 - 584
iii
The outcome will be an efficient avionic development and testing test bed suitable for
technology assessment, development and validation. The same system will be
efficiently reused for software simulation, prototyping and eventually certification.
Additionally, interaction of the avionics software with the physical environment will
be tested seamlessly at each phase using the same physical world model. Provision
will be made to ensure that the system will also support real world interaction for live
testing.
David Prevost, September 2007. « Mise sur pied d’un banc d’essai pour l’évaluation, le
développement, le prototypage, la simulation et la validation de technologies
avioniques » CR 2007-? Defence R&D Canada – Valcartier.
iv
CR 2007 - 584
Sommaire
RDDC Valcartier propose de développer son expertise en développement et tests de systèmes
avioniques en étudiant des outils et techniques pour analyser l'interaction logicielle avec son
environnement physique. Ceci inclut : 1) Stimuler les logiciels au niveau de leur interface, 2)
Émuler des systèmes avioniques qui agissent les uns sur les autres par des signaux discrets
d'entrée-sortie ou par le bus avionique, 3) Effectuer l'injection de signal dans les unités de
traitement de signaux des senseurs.
Les Forces canadiennes ont mis au point un ensemble sophistiqué d'outils de développement
logiciel et d'équipements de test qui ont augmenté la productivité, la qualité et la fiabilité des
programmes opérationnels de vol (OFP) développés pour le CF-18. Un de ces outils est la
station d’essai pour le prototypage et la simulation de l'avionique du CF-18 (ASPB). L'ASPB
est un simulateur fonctionnant sur PC qui utilise des émulateurs et des modèles produisant un
CF-18 virtuel à faible coût. Ce dernier permet de réduire de manière significative le besoin
d’utiliser la véritable avionique de l’aéronef. Ainsi, moins de stations d'essai avec matériel
dans la boucle sont nécessaires, réduisant de ce fait les coûts d'entretien et améliorant la
fiabilité. Puisque l'ASPB exécute le code réel d'avion (MC, SMS, CSC et MDG), le système
est mis à jour avant la flotte lorsque de nouveaux OFPs sont libérés, le rendant idéal pour la
familiarisation et la formation des pilotes.
RDDC désire utiliser l'ASPB pour étudier la faisabilité d'exécuter des techniques robustes de
désignation laser du CF-18 aux contre-mesures. Ces techniques sont actuellement à l'étude
dans le projet 13ev « Improved smart-weapons tracking and discrimination in a
countermeasure rich environment ».
Actuellement, les CF-18 sont soumis à un projet de modernisation qui inclut des systèmes
nouveaux et améliorés dans les domaines de l'avionique et des armes. Cependant, avec la
technologie en pleine évolution, même le CF-18 modernisé souffrira bientôt de limitations au
niveau des possibilités d’amélioration et de la désuétude de ses systèmes. Les Forces
canadiennes ont mandaté le « System Engineering Support Contract (SESC) » pour étudier la
faisabilité de concepts avancés et de technologies émergentes pour le CF-18 sous l'initiative
du « Advanced Concepts & Technologies (ACT) ». Afin de mener à bien le mandat qui leur a
été confié, SESC développe un nouvel outil nommé « Multi-Purpose Computing Unit
(MPCU) ». Le MPCU est une plateforme de prototypage avionique en temps réel pour
étudier de nouveaux concepts et technologies, par exemple : le transfert de données à grande
vitesse, les futures possibilités de calculs, les commandes vocales (reconnaissance de la
parole) et le transfert d’images sur le MIDS.
RDDC entend employer le MPCU pour évaluer de nouveaux concepts actuellement à l'étude
dans le projet 13ew « réseau Network Enabled Weapons for Tomorrow’s Precision Strike ».
Les objectifs de ce projet sont : capturer les spécifications opérationnelles et technologiques
requises pour les effets de précision en réseau, définir et évaluer l'espace de solution des
concepts viables d'armes de précision et des technologies basées sur des composantes, fournir
des recommandations pour les options les plus prometteuses. Pour réaliser cela, RDDC veut
CR 2007 - 584
v
étudier des technologies de communications militaires en utilisant la plateforme de
prototypage avionique temps réel (MPCU).
Le résultat attendu sera la mise sur pied d’un banc d'un essai efficace pour réaliser
l'évaluation, le développement et la validation de technologies avioniques. Le même système
sera également réutilisable pour la simulation, le prototypage et éventuellement la certification
logicielle. De plus, l'interaction des logiciels avioniques avec l'environnement physique sera
examinée à chaque phase en utilisant le même modèle d’environnement. Finalement, des
dispositions seront prises afin de s'assurer que le banc d’essai pourra également supporter des
interactions avec les systèmes opérationnels lors de tests réels.
David Prévost, septembre 2007. « Mise sur pied d’un banc d’essai pour l’évaluation, le
développement, le prototypage, la simulation et la validation de technologies avioniques
» CR 2007-? R & D pour la défense Canada – Valcartier.
vi
CR 2007 - 584
Page intentionnellement laissée en blanc.
CR 2007 - 584
vii
Table des matières
Executive summary ................................................................................................................... iii
Sommaire.................................................................................................................................... v
Table des matières ................................................................................................................... viii
Liste des figures.......................................................................................................................... x
Liste des tableaux ..................................................................................................................... xii
Vue d’ensemble .......................................................................................................................... 1
1.
Manipulation avec le MIL-STD-1553........................................................................... 2
1.1
1.2
2.
viii
Description sommaire du MIL-STD-1553 ....................................................... 2
1.1.1
Bus de données 1553 ........................................................................... 3
1.1.2
MIL-STD-1760 ................................................................................... 3
Carte Condor .................................................................................................... 4
1.2.1
Outil BusTools Visual Analyzer for Windows.................................... 4
1.2.2
Utilisation sous Matlab/Simulink ........................................................ 5
1.2.3
Exemple d’un scénario Simulink......................................................... 8
ASPB : Simulateur CF-18 ........................................................................................... 11
2.1
Démarrage du simulateur ............................................................................... 12
2.2
L’API GsAPI .................................................................................................. 14
2.3
Autres informations ........................................................................................ 16
2.4
Manipulations possibles ................................................................................. 18
2.5
HOTAS Cougar .............................................................................................. 21
2.6
Développement en cours de l’ASPB par le SESC.......................................... 23
2.7
Blocs Simulink de l’API : ASPBLibrairy...................................................... 23
2.8
Interfaçage avec des scénarios Simulink GGM.............................................. 23
2.8.1
Modification du fichier GGMBaseLine ............................................ 24
2.8.2
Modification du fichier MultiGGM................................................... 29
2.8.3
Validation de la physique de l’ASPB................................................ 31
CR 2007 - 584
3.
PC/104 ......................................................................................................................... 36
3.1
4.
MPCU.......................................................................................................................... 39
4.1
5.
Carte PC/104 compatible 1553....................................................................... 38
VxWorks ........................................................................................................ 39
Utilisations possibles de bancs d’essais....................................................................... 40
5.1
Système sans utilisation directe du MIL-STD-1553/1760 ............................. 40
5.2
Système avec MIL-STD-1553/1760............................................................... 42
6.
Exemple d’utilisation futur.......................................................................................... 44
7.
Conclusion................................................................................................................... 47
8.
Références ................................................................................................................... 49
Annexes .................................................................................................................................... 50
Liste symboles/abrév./acronymes/sigles................................................................................... 62
Liste de distribution .................................................................................................................. 65
CR 2007 - 584
ix
Liste des figures
Figure 1. Montage complet du système...................................................................................... 1
Figure 2. Logiciel BusTools Visual Analyzer for Windows ...................................................... 5
Figure 3. Exemple Simulink avec la Carte Condor .................................................................... 8
Figure 4. Blocs utilisés par le Remote Terminal ........................................................................ 9
Figure 5. Blocs utilisés par le Bus Controller........................................................................... 10
Figure 6. Systèmes avioniques du CF-18 émulés et simulés dans l’ASPB .............................. 11
Figure 7. Interface graphique de l’ASPB ................................................................................. 12
Figure 8. Mode auto acquisition avant la détection d’une cible ............................................... 19
Figure 9. Configuration de l’ASPB avec un AIM-9 miré sur une cible ................................... 19
Figure 10. Configuration de l’ASPB avec un GBU24 en mode automatique ......................... 21
Figure 11. Panneau de configuration du HOTAS..................................................................... 22
Figure 12. Intérieur du bloc CF-18 du scénario GGMBaseLineASPB .................................... 25
Figure 13. Bloc affichant la cible dans l’ASPB....................................................................... 25
Figure 14. Intérieur du bloc de la cinématique du CF-18 dans le scénario
GGMBaseLineASPB ........................................................................................................ 26
Figure 15. Grossissement de l’intérieur du bloc de cinématique.............................................. 26
Figure 16. Intérieur du bloc activant l’événement LaunchTrigger de GGMBaseLineASPB... 28
Figure 17. Intérieur du bloc affichant la cible dans l’ASPB..................................................... 28
Figure 18. Intérieur du bloc F-18 du scénario MultiGGM ....................................................... 30
Figure 19. Grossissement de l’intérieur du bloc CF-18 du scénario MultiGGM ..................... 30
Figure 20. Bloc activant l’événement triggerLaunch de MultiGGM ....................................... 31
Figure 21. Comparaison des trajectoires entre GGMBaseLineASPBValidation(gauche) et
GGMBaseLineValidation(droite)...................................................................................... 33
x
CR 2007 - 584
Figure 22. Comparaison du LOS entre GGMBaseLineASPBValidation(gauche) et
Figure 23. Comparaison de l’accélération entre GGMBaseLineASPBValidation(gauche) et
Figure 24. Carte PC/104+ avec bus ISA et PCI........................................................................ 36
Figure 25. Modèle de bombe et ASPB avec GsAPI ................................................................. 40
Figure 26. Modèle de bombe et ASPB communiquant avec 1553overIP ............................... 41
Figure 27. Modèle de bombe et ASPB communiquant avec 1553/1760.................................. 42
Figure 28. Modélisation de la communication d’une bombe dans un vrai CF-18.................... 44
Figure 29. Modélisation de la communication entre un modèle de bombe et le simulateur du
CF-18................................................................................................................................. 45
Figure 30. Modélisation de la communication entre un modèle de bombe et un CF-18.......... 46
CR 2007 - 584
xi
Liste des tableaux
Tableau 1. Vitesse de transfert sous le logiciel BusTools et Simulink...................................... 6
Tableau 2. Problème rencontré avec xPC Target et Carte Condor............................................ 7
Tableau 3. Description des fichiers de configuration des différentes stations.......................... 13
Tableau 4. Description des armements disponible dans l’ASPB.............................................. 15
Tableau 5. Exemple d’un message 1553 dans le fichier de configuration de l’ASPB ............. 17
Tableau 6. Exemple de code utilisant un message 1553 des fichiers de configuration de
l’ASPB .............................................................................................................................. 17
Tableau 7. Conversions nécessaires pour utiliser la cinématique de l’ASPB dans un scénario
Simulink ............................................................................................................................ 27
Tableau 8. Conversions nécessaires pour l’affichage d’une entité dans l’ASPB à partir d’un
scénario Simulink.............................................................................................................. 29
Tableau 9. Carte PC104-1553 de Data Device Corp. ............................................................... 38
Tableau 10. Carte PC104-1553 de Condor............................................................................... 38
xii
CR 2007 - 584
Vue d’ensemble
Le laboratoire avec tous les systèmes matériels devait ressembler à la figure 1. Un
exemple du fonctionnement de ce laboratoire pourrait consister d’un MPCU qui
simule une composante matérielle du CF-18 ou bien un modèle Simulink. Le MPCU
demande de l’information via le réseau 1553 à d’autres composantes du CF-18 qui
sont eux émulés/simulés de façon logicielle sur l’ASPB. D’autres systèmes matériels
pourraient être configurés pour interagir avec le MPCU et ASPB comme un PC/104.
De façon plus détaillée, les différentes pièces du réseau 1553 sont des câbles coaxiaux,
un « 5-stub coupler » et des « Terminator » de 78 ohms et 3000 ohms. Le MPCU et
l’ASPB communiquent via ce réseau 1553. Optionnellement, une carte PC/104
compatible 1553 embarquée sur une autre carte PC/104 (PC/104+ ou PCI-104) avec
processeur pourrait être installée sur le réseau. Le MPCU et PC/104 sont aussi
connectés à un ordinateur Host via un lien Ethernet. Les Hosts servent pour le
développement des scénarios. L’outil Tornado est utilisé pour le développement sous
VxWorks (non testé). Pour construire des scénarios Simulink sous xPC Target,
Matlab/Simulink/RTW doit être installé sur le Host (testé de façon préliminaire avec la
carte condor PCI-1553).
Figure 1. Montage complet du système
CR 2007 - 584
1
1.
Manipulation avec le MIL-STD-1553
1.1 Description sommaire du MIL-STD-1553
MIL-STD-1553 est un protocole de communication utilisé dans plusieurs types
d’avions entre autres le CF-18. Ce protocole permet aux différentes boîtes avioniques
de communiquer entre elles et donc d’échanger des données. Ces échanges se font de
façon maître/esclave. Dans le 1553, le maître est un « Bus Controller » (BC) et les
esclaves sont soit un « Remote terminal » (RT) ou un « Bus monitor » (BM). Le Bus
Controller a le contrôle exclusif du bus de données donc, c’est lui qui dicte au Remote
Terminal le moment où il peut envoyer des données. Le Bus Monitor sert seulement à
collecter des données sur le bus à des fins d’affichage ou de stockage.
Les données échangées sur le bus sont composées de 20 bits en tout, mais seulement
16 bits sont des données. Trois des quatre bits manquants servent à la synchronisation
et le quatrième bit sert à la correction d’erreur (bit de parité). Les données de 20 bits
se nomment des mots (« word ») et il en existe trois sortes : « command word », «
status word » et « data word ». Les commandes word sont utilisées seulement par le
Bus Controller pour dicter les actions que le Remote Terminal doit faire sur le bus. Le
status word est essentiellement utilisé par un Remote Terminal pour indiquer que le
message a été reçu sans erreurs. Les données à échanger sont envoyées grâce au data
word. Donc, l’envoie d’un message 1553 se compose normalement des trois types de
mots (word) énumérés plus haut. Noter que seulement 1 command word et 1 status
word sont utilisés, mais qu’il peut y avoir jusqu’à 32 data word par message. Par
exemple, pour l’envoie d’un message quelconque du BC à un RT, il y aura les étapes
suivantes :
1) Envoie du command word du BC vers le RT lui spécifiant qu’il doit se
préparer à recevoir des données
2) Envoie des données du BC vers le RT grâce à un ou plusieurs data word
3) Suite à la réception de toutes les données, le RT répond au BC avec un status
word pour indiquer la réussite de la transmission des données.
La procédure pour l’envoie d’un message d’un RT vers un BC, d’un RT vers un RT ou
de broadcoast est un peu différente.
Certains messages, transmis seulement par le Bus Controller et se nommant « Mode
Code » ou « Mode Command », sont constitués d’un command word spécifique.
Ceux-ci sont particuliers, car lorsque utilisés, ils doivent suivre à la lettre le standard
1553.
Souvent, le trafic sur un système 1553 est périodique suivant des listes de messages
prédéfinies. Ces listes sont normalement séparées par trame nommée « minor frame »
et le regroupement de ces trames est nommé « major frame ». Comme ce major frame
2
CR 2007 - 584
est périodique, alors une fréquence lui est associée indiquant le nombre de fois par
seconde que la trame sera envoyée sur le bus.
Les différents détails sur les 3 types de mots et sur la façon dont les messages sont
envoyés sont bien expliqués dans tout tutoriel sur le 1553. Condor (GE Embedded
systems) et Data Device Corporation (DDC) ont mis en ligne une version PDF de ces
tutoriels. Le fichier PDF « MIL-STD-1553 Designer’s guide » de DDC décrit plus en
détails certaines particularités du protocole qui permet de mieux le comprendre.
Il faut aussi souligner que normalement lorsque le protocole 1553 est implanté dans un
appareil, comme un CF-18, une liste de messages 1553 est déjà prédéfinie spécifiant
toutes les données qui sont échangées sur les différents bus de données. Donc, si on
veut interagir avec une composante, il faut utiliser ces messages prédéfinis.
1.1.1 Bus de données 1553
Le bus de données du protocole 1553 est composé d’un câble coaxial et les
BC, RT et BM sont branchés avec un autre câble sur ce bus de façon « direct
coupled » ou « transformer coupled ». En gros, le « direct coupled » permet
l’utilisation de câbles de 1 pied tandis que le « transformer coupled » permet
jusqu’à 20 pieds. Normalement, une configuration 1553 comprend les câbles
en double, car le protocole est redondant : les mêmes données sont envoyées
sur deux câbles (MUX A et B), permettant ainsi une configuration plus
robuste. Encore une fois, pour plus de détails se référer aux tutoriels sur le
1553.
De notre côté, seulement un stub coupler 5 ports de Data Bus Product a été
utilisé pour interconnecter les différentes entités (voir figure 1). D’une
certaine façon, il joue le rôle du bus et les entités se connectent de façon
« transformer coupled ». Les connecteurs à chaque extrémité du stub coupler
permettent l’ajout de câbles pour prolonger le bus de données et ainsi
brancher d’autres entités en utilisant des « stub coupler » supplémentaires.
Par contre, si ces connecteurs ne sont pas utilisés, il faut mettre des
« terminator » 78 ohms pour éviter la réflexion des signaux. Les 5 ports sur
le côté du stub coupler servent à connecter les BC, RT et BM avec les câbles
de 20 ou 10 pieds. Les ports inutilisés (sur le côté et non sur l’extrémité)
doivent être terminés par les « terminator » 3000ohm. Prendre note que
d’après certaines sources/compagnies, il serait préférable de laisser ces ports
sans « terminator », mais que d’autres suggèrent de les terminer. Aussi, cette
configuration ne permet pas la redondance.
1.1.2 MIL-STD-1760
Dans un CF-18, ce protocole est surtout utilisé pour la communication entre
les armements et le Stores Management System (SMS). Il est une couche
par-dessus le MIL-STD-1553. Ce rajout permet d’avoir une meilleure
validation des messages grâce au Cyclic Redundancy Check (CRC). De plus,
CR 2007 - 584
3
l’adresse des Remote Terminal peut être assignée de façon matérielle. Aussi,
avec le 1760, la première réponse d’un RT peut se faire dans un délai très
court (150ms) avec le bit Busy du status word. Ce standard définit aussi
certains messages pour la communication avec des armes. Quelques détails
supplémentaires sont disponibles dans l’annexe, mais pour une description en
profondeur se référer au fichier du standard.
1.2 Carte Condor
La carte condor utilisée (PCI-1553M) permet d’interfacer un ordinateur sur un réseau
1553. Cette carte est multifonction, ce qui lui permet d’être 1 BC, 32 RT et 1 BM en
même temps. Cette caractéristique permet de simuler des systèmes 1553 simplistes
seulement avec une carte et sans câblage. De plus, cette carte possède seulement 1
canal donc, il peut être connecté à un seul réseau 1553, mais chaque canal comprend
toujours 2 câbles coaxiaux pour la redondance. La carte est compatible avec plusieurs
systèmes d’exploitation comme Windows, Linux et VxWorks. Un API de langage C
est fournie. Aussi un logiciel « BusTools Visual Analyzer » est disponible avec des
coûts supplémentaires.
1.2.1 Outil BusTools Visual Analyzer for Windows
BusTools Visual Analyzer fonctionne seulement sur Windows et avec les
cartes multifonctions. Il permet une utilisation sans programmation de la
carte. Cet outil permet la création de messages périodiques et apériodiques.
Par contre, les événements apériodiques peuvent seulement être déclenchés
par l’utilisateur. L’outil est utile pour tester des scénarios avec des messages
prédéfinis. Les données à transférer entre entités sont inscrites directement à
la main dans l’outil ou peuvent être préalablement importées d’un fichier. De
plus, il faut toujours spécifier de quels types (16bits, 32bit, hex, BCD) sont
les données. Le logiciel permet aussi de créer des messages conditionnels.
Une partie intéressante du logiciel est le bus monitor. Ce dernier permet
d’enregistrer tout le trafic sur le bus de données dans un fichier et d’en faire
une analyse. L’outil permet d’afficher les messages de façon séquentielle
avec les données brutes (en binaire) ou décodées selon le type désiré (16 bits,
32bits, hex, etc).
4
CR 2007 - 584
Figure 2. Logiciel BusTools Visual Analyzer for Windows
Finalement, il est possible d’ajouter des DLL au logiciel et ainsi augmenter
les fonctionnalités de l’application grâce à la programmation C/C++.
1.2.2 Utilisation sous Matlab/Simulink
Les pilotes Simulink développés par Mathworks fonctionnent avec les cartes
PCI, QPCI et Q104 de condor. Pour les utiliser, il faut un ordinateur Host
sous Windows possédant Matlab/Simulink/Real-Time Workshop et un autre
ordinateur nommé Target. Ce dernier, pourvu de la carte condor, doit
démarrer avec une disquette possédant un système d’exploitation en temps
réel nommé xPC Target. La configuration de la disquette se fait via xPC
Explorer un outil de Matlab. La communication entre les deux ordinateurs se
fait via un réseau Ethernet ou le port série en fonction de la configuration
choisie. La façon de procéder pour utiliser ce montage est la suivante: on
insère les blocs Simulink comme n’importe quel scénario Simulink, ensuite
grâce à Real-Time workshop (RTW), on compile le scénario en code
C/C++ qui est transféré dans le Target. Il ne reste juste qu’à démarrer la
simulation.
L’utilisation de la carte dans Simulink est un peu plus complexe que l’outil
BusTools. Les données choisies pour le transfert entre entités doivent
absolument être divisées en mot de 16 bits, ce qui alourdit son utilisation. De
plus, le Bus Monitor est plus compliqué à utiliser et il ne possède aucun outil
CR 2007 - 584
5
de post analyse. L’implantation des pilotes utilise seulement le mécanisme
apériodique pour l’envoie de message, ce qui semble diminuer la vitesse
maximale atteignable. Des tests pour transférer 32 mots de 16 bits ont été
effectués. Le logiciel Bus Tools (utilisant le mécanisme périodique) pouvait
utiliser un pas entre chaque message de 0,0014 seconde (700Hz), tandis que
même à 0,01 seconde (100Hz) Simulink/xPC Target avait de la difficulté
après quelques minutes : des messages d’erreur de l’API de condor
s’affichaient sur l’interface graphique de xPC Target.
En réalité, lors d’un transfert de 32 mots de 16 bits de données, il y a un
« command word » et « status word » qui se rajoute. De plus, il y a aussi les
bits de synchronisation (3 bits) et le bit de parité. Donc, avec les en-têtes, il y
a en tout 34 mots de 20 bits qui sont transférés. Le tableau 1 donne les
vitesses calculées avec et sans en-tête par rapport au pas de temps mentionné
plus haut. En se rappelant que la vitesse maximale du 1553 est de 1Mb/sec (1
000 kb/sec), on constate que le logiciel BusTools en utilise environ 50%,
mais que pour les simulations Simulink, c’est à peine 10%. La raison de cette
faible vitesse via Simulink est en partie dû à l’implantation du mécanisme
apériodique dans les blocs 1553 qui est beaucoup moins optimisé que le
mécanisme périodique utilisé dans Visual Analyzer. De plus, compte tenu
des différentes couches impliquées dans l’utilisation des blocs 1553 sous
Simulink/xPC Target, il est clair qu’au départ, les blocs 1553 sont moins
performants que le logiciel développé par Condor.
Tableau 1. Vitesse de transfert sous le logiciel BusTools et Simulink
LOGICIELS
VITESSE AVEC EN-TÊTE
VITESSE SANS EN-TÊTE
BusTools Visual Analyzer
485,71 kb/sec (60,71 kB/sec)
365,71 kb/sec (45,71 kB/sec)
Bloc 1553 Matlab/Simulink
68kb/sec (8,5kB/sec)
51,2kbt/sec (6,4kB/sec)
kb/sec = kilobit / seconde, 1 kilobit = 1000 bits
kB/sec = kiloByte / seconde, 1 kiloByte = 1000Byte
Durant les différents essais d’utilisation de la carte Condor avec Simulink
quelques outils ont été utilisés. Certains outils de Simulink permettent
l’affichage en temps réel des données. Le Host Scope affiche les données sur
l’ordinateur Host, mais, avec les essais effectués, les données étaient mises à
jour peu fréquemment, donc l’affichage des graphiques n’était plus vraiment
en temps réel. En plus, lorsque le « refresh » était désactivé, pour pallier un
bogue, les scopes ne se rafraîchissaient plus. Le Target Scope ne permet pas
de faire des analyses précises, car il affiche de façon très grossière des
graphiques sur l’écran du Target. Il est utile pour voir un aperçu des données
et détecter si quelque chose est anormal dans la simulation. Une autre façon
de récupérer des données en temps réel est d’utiliser les blocs UDP pour les
6
CR 2007 - 584
envoyer via un lien Ethernet, ainsi un ordinateur distant récupère et traite ces
données. Finalement, en activant « save to workspace » dans les options du
Real-Time WorkShop, il est possible de récupérer à la fin de la simulation les
données qui sont envoyées dans des blocs « output port ». Il faut cliquer sur
le bouton « send to Matlab Workspace » dans l’outil xPC Explorer pour que
les données soient transférées dans l’espace de Matlab et ainsi le rendre
disponible à du post traitement. Il faut préalablement être connecté sur le
Target et avoir téléchargé un scénario avec RTW.
Tableau 2. Problème rencontré avec xPC Target et Carte Condor
ERREUR/ PROBLÈME
SOLUTION
xPC Target ne détecte pas la carte réseau
xPC est très restreint sur les cartes réseaux compatibles, donc nous avons utilisé la
carte Intel Pro/100M. D’autres cartes sont compatibles, se référer à l’aide de
Matlab/Simulink.
Lorsque xPC Explorer est connecté à un Target via
un
lien
Ethernet,
le
message
d’erreur
suivant s’affiche :
Mathworks considère ce problème comme un bogue à corriger. Une solution possible
est de choisir « disable Refresh » dans le menu « tool » de xPC Explorer. Cela aura
comme effet que les données, provenant du Target et affichées dans xPC Explorer, ne
seront plus mises à jour périodiquement.
« Error using => tg.xpctarget.xpc.getscope at 77.
TCP/IP Read error ».
Lors de la modification/recompilation d’un scénario
Simulink le message d’erreur suivant apparaît :
« Error building Real-Time Workshop target for block‘
diagram '’modelName'’. MATLAB error message:
Error using ==> RTW.genMakefileAndBuild at 967
Error(s) encountered while building model
"modelName”.»
Solution 1 : Une solution existe sur le support de Mathworks mais qui n’a pas
fonctionné pour ma part :
http://www.mathworks.com/support/bugreports/details.html?rp=361994
Solution 2 : Lancer une seconde fois la compilation avec RTW.
En utilisant les blocs Simulink, les messages
broadcastés ne semblent pas fonctionner.
Il faut activer l’option « RT 31 is broadcast » dans le bloc d’initialisation de la carte. De
plus, il faut absolument utiliser un bloc « RT receive message » avec la « subaddress »
31 pour recevoir les messages du côté des Remote Terminal.
L’envoie de messages entre 2 RT ne fonctionne pas :
lorsque la simulation est démarrée xPC Target
bloque à Running
Ce problème est un bug avec xPC Target. Un correctif existe, mais ne semble pas être
présent sur le support de Mathworks pour le moment. La procédure et le fichier
nécessaire pour la correction du problème sont dans les dossiers partagés du projet
Avionic (sur l’ordinateur à Éric Dumais au moment de la rédaction de ce document).
La simulation sur xPC Target indique le statut CPU
overloaded et un des messages d’erreur suivant
apparaît :
Ce problème est dû à un temps de simulation trop rapide, donc il faut diminuer le pas.
Ces messages d’erreur viennent de l’API de Condor utilisé dans les pilotes de Matlab
pour la carte PCI-1553.
« BusTools_BC_AperiodicRun : BC Aperiodics still
running, cannot start new message list»
« BusTools_BC_AperiodicRun :
messages did not complete in time»
BC
Aperiodic
Logiciel utilisé :
•
Matlab R2007a (xPC Target 3.2)
•
Visual Studio 7.1 (2005)
CR 2007 - 584
7
1.2.3 Exemple d’un scénario Simulink
L’exemple suivant démontre le transfert de données de type double (64bits)
entre un Bus Controller et un Remote Terminal. Les données transférées qui
sont différents signaux sont affichées sur l’écran du Target. Cet exemple a
pour but de montrer comment échanger des données plus grandes que 16 bits,
car l’entrée des blocs de transfert accepte seulement des données de type
uint16.
Figure 3. Exemple Simulink avec la Carte Condor
La figure 3 montre les composantes du scénario soit le Remote Terminal #1
et le Bus Controller. Les Target Scope permettent d’afficher graphiquement
les données reçues par le BC. Le bloc « Initialization » contient des blocs
d’initialisation de la carte et du Remote Terminal. Ainsi, la carte est
initialisée pour l’utilisation d’un BC et RT sur le canal A. Aussi, le Remote
Terminal est configuré comme étant le #1 communiquant via les sousadresses 0 et 3.
La figure 4 illustre les différents signaux de type double qui sont regroupés et
convertis dans un vecteur faisant 32 mots de 16 bits. Le bloc Bit Packing
permet la division de données de 64bits en 16bits. Ensuite, le bloc « 1553
send » envoie les données au BC. Le « Chan 1 : 1-T-3-32 » indique que le
RT #1 transmet, via la sous-adresse 3, 32 mots sur le canal 1.
8
CR 2007 - 584
Figure 4. Blocs utilisés par le Remote Terminal
La figure 5 montre les blocs associés au BC. Comme énoncé dans la section
du protocole 1553, les messages 1553 sont souvent utilisés avec une liste.
Donc, le bloc le plus à gauche, permet d’initialiser une liste qui contiendra
tous les messages échangés sur le bus. Le bloc suivant permet de créer un
message et de l’insérer dans la liste. Dans notre cas, le message indique que
le RT #1 transmet 32 mots avec la sous-adresse 3. Ensuite, le bloc « Bus
Controller » envoie les messages successivement avec un certain délai entre
chaque message pour laisser un temps de réponse et de traitement. Ce bloc
emmagasine aussi les données reçues, mais elles sont décodées par le bloc
« Decode 1553 Message » qui donne en sortie des données de 16bits. Le bloc
« Bit Unpacking » transforme ces données de 16bits en données de 64bits
pour retrouver les données d’origine.
CR 2007 - 584
9
Figure 5. Blocs utilisés par le Bus Controller
Donc, à chaque pas de temps, le BC envoie sur le bus le message décrit plus haut et le
RT répond en envoyant les signaux transformés de 64bits en 16bits. Le BC reçoit ces
données les remets en 64bits et les affichent sur l’écran du Target. Ce processus se
répète jusqu’à la fin de la simulation.
10
CR 2007 - 584
2.
ASPB : Simulateur CF-18
L’ASPB ou MCTS pour Mission Computer Test Station est un simulateur du CF-18
développé par le SESC à Mirabel. Ce logiciel émule les composantes du CF-18 et
donc aussi le réseau MIL-STD-1553/1760 servant au transfert de données entre ces
différentes composantes. Les boîtes orange et bleu de la figure 6 illustrent les parties
du CF-18 émulées/simulées dans l’ASPB. L’Avionics Multiplex Bus (AMVUX)
englobe six réseaux 1553 et l’Armament Multiplex Bus (ARMUX) est le bus de
données utilisant le 1760. Les Mission Computer et l’Armament Control Processor
(ACP) (une partie du Stores Management System (SMS)) sont respectivement les Bus
Controller de l’AVMUX et L’ARMUX.
Figure 6. Systèmes avioniques du CF-18 émulés et simulés dans l’ASPB
Noter que les deux MC sont probablement utilisés en alternance, car il est impossible
d’avoir deux Bus Controller au même moment sur le même bus de données. Par
CR 2007 - 584
11
contre, le SMS est un BC sur l’Armament Bus et est aussi un Remote Terminal sur
l’Avionics Bus.
Aussi, la présente version de l'ASPB ne contient pas le supplément classifié (voir
annexe G).
Figure 7. Interface graphique de l’ASPB
2.1 Démarrage du simulateur
Pour démarrer l’ASPB, il faut suivre les étapes suivantes :
1. Démarrer l’émulateur des Mission Controller nommé MC_Emulator
(MCE_Color ou MCE_Monochrome).
2. Double cliquer sur le Station Loader Client
3. Désélectionner « Check Release integrity »
12
CR 2007 - 584
4.
5.
6.
7.
8.
9.
10.
Cliquer sur « Start Current Version »
Ensuite, il faut charger une station dans « File, Load Station »
Choisir ASPB_ECP1_modified ou ASPB_ECP2_modified
(Optionnel) Choisir l’armement désiré dans la section « Stores »
Charger les fenêtres graphiques dans « File, Restore Window layout »
Choisir un des fichiers avec l’extension .lay
Cliquer sur le bouton Play pour démarrer le scénario.
Une fois que toutes les étapes mentionnées sont complétées, une fenêtre semblable à la
figure 7 devrait être affichée. Les différentes fenêtres, sauf deux, représentent une
partie des boutons que l’on retrouve sur le tableau de bord d’un vrai CF-18. La grande
majorité des boutons sont fonctionnels avec la souris, mais dû à un problème avec la
carte graphique utilisée, les boutons en haut du Sensor Control Panel sont non
fonctionnels avec la souris. De plus, les boutons suivants du panneau LH Vertical
Control Panel ne sont pas encore implantés : FLAP, ANTI SKID, LGD/Taxi light,
Hook bypass. Pour des détails sur le HOTAS, voir la section 2.5.
Le tableau 3 montre les fichiers de configuration des scénarios disponibles. Dans
notre cas, compte tenu qu’aucune partie du CF-18 n’est simulée par une composante
matérielle, alors les seuls fichiers de station utilisables sont ASPB_ECP1_modified et
ASPB_ECP2_modified. La configuration SITO pourrait être utilisable, mais les
fichiers de chargement des Mission Controller sont inexistants sur le disque dur.
Tableau 3. Description des fichiers de configuration des différentes stations
FICHIER DE
CONFIGURATION
(.CFG)
ASPB_ECP1
ASPB_ECP2
DESCRIPTION
• Les Mission Controller (MC) sont émulés par un logiciel
• Configuration pour 17CC (ECP-R1, 1re modernisation)
• Les modèles de Left and Right Digital Display Indicator (LDDI, RDDI) sont
disponibles pour le Multipurpose Display Indicator (MDI) de type Non-Night Attack
Digital Display (NNADDI)
• Fichiers des Mission Controller sont inexistants
• Les Mission Controller (MC) sont émulés par un logiciel
• Configuration pour 19CC (ECP-R2, 2e modernisation)
• Les modèles de Left/Right Multipurpose Display Indicator (LMDI, RMDI) et Digital
Map Set sont disponibles pour le Multipurpose Display Indicator (MDI) de type
Multi-purpose Display Group Upgrade (MDGU)
• Fichiers des Mission Controller sont inexistants
ASPB_ECP1_modified
IDEM à ASPB_ECP1, mais modifié pour utiliser des fichiers de MC existant.
ASPB_ECP2_modified
IDEM à ASPB_ECP2, mais modifié pour utiliser des fichiers de MC existant.
MCTS_ECP1
Les MC et l’Advanced Unit Memory (AMU) sont des composantes matérielles
MCTS_ECP2
Les MC et l’Advanced Unit Memory (AMU) sont des composantes matérielles
SITO
Les MC sont émulés par un logiciel, mais leur fichier de chargement est inexistant
Le Multi-purpose Display Group Upgrade (MDGU) réfère au nouveau Display mis en opération lors de la deuxième
modernisation des appareils. Ce nouveau système utilise des écrans LCD 14 couleurs et des cartes digitales. Le
Non-Night Attack Digital Display (NNADDI) est la version antérieure en noir et blanc.
CR 2007 - 584
13
Noter que si les stations ASPB_ECP1 et ASPB_ECP2 sont utilisées, alors le MC
Emulator ne chargera pas correctement le MC2. Ce problème vient du fichier de
configuration qui utilise des noms de fichier de MC inexistant sur le disque dur, donc
par défaut, il affecte le premier fichier trouvé pour les deux MC.
2.2 L’API GsAPI
L’installation de l’ASPB vient avec un API nommé GsAPI qui implante plusieurs
fonctions permettant de jouer avec le simulateur. De notre côté, l’API a permis
d’interfacer le simulateur avec Simulink. Ainsi, plusieurs blocs ont été développés
pour configurer et manipuler l’ASPB à partir de Simulink (voir section 2.7). Une
version « StandAlone » permet de développer avec l’API sans l’ASPB, mais elle reste
limitée au niveau de l’exécution. Cette version de l’API se retrouve sur le cd « CD
MCTS Tools And Demo Project Version 3.0.4 ».
La section Flight Control de l’API (d’après le fichier d’aide GsApiV1.chm) possède
plusieurs fonctions qui affectent le CF-18 lors du chargement d’une station dans
l’ASPB. Ces fonctions peuvent entre autres modifier la position, l’orientation, la
vitesse, vitesse angulaire, etc. Pour contrôler d’autres avions, il faut premièrement en
créer avec la fonction createEntity disponible dans la section Synthetic Environment.
C’est l’interface IEntity qui permet de modifier les paramètres des avions créés comme
Flight Control fait pour l’avion principal. Noter que seulement deux fichiers de
modèles graphiques sont disponibles dans les dossiers du simulateur, donc le même
modèle graphique sert pour presque tous les types d’entités et, quelquefois, le modèle
n’est pas du tout représentatif de l’entité désirée. Par exemple, pour l’AIM-9, c’est un
modèle graphique d’un tank qui est chargé.
La section Avionics Panel regroupe plusieurs panneaux du tableau de bord du CF-18.
Elle implante des fonctions permettant de positionner les boutons des différents
panneaux, ainsi cela devient utile pour initialiser l’avion dans un état désiré ou bien
pour simuler la présence d’un pilote. Noter qu’il faut utiliser la section Multi-Display
Group pour tous les boutons des panneaux suivants: Left/Right Digital Display
Indicator, Horizontal Situation Indicator, Head Up Display(LDDI, RDDI, HSI, HUD).
Pour le panneau Up-Front Control Panel (UFC), il faut se référer à la section du même
nom. Finalement, pour simuler l’utilisation du hands on throttle-and-stick (HOTAS),
il faut utiliser la section HOTAS Control.
La section Store Loading permet de simuler la présence de différents armements. Le
tableau 4 décrit tous les types de bombes/missiles disponibles dans le simulateur. La
présence graphique indique si l’armement choisi s’affiche graphiquement dans la
fenêtre Flight View.
14
CR 2007 - 584
Tableau 4. Description des armements disponible dans l’ASPB
ACRONYME
F330
F480
RE T
RE
GATR
76
106
48
84
84 T
84LG
83B
83P
83BT
83PT
83CT
83LG
82B
82P
82BT
82PT
82X
82XT
82YT
82SB
82SP
82LG
GB24
SU S
SU R
MAVF
MAVG
61 S
61 R
68 S
68 R
10 S
10 R
9M
9L
TST
7F
7M
7H
7P
R6 S
R6 R
R10S
R10R
BAG
DESCRIPTION
Fuel Tank 330 gallon (Can)
Fuel Tank 480 gallon (Can)
MK-20 Rockeye II MOD 6 (TP)
MK-20 Rockeye II
CBU-78/B Gator
MK-76 Practice Bomb (Conventional Usage)
MK-106 Practice Bomb (Conventional Usage)
BDU-48/B Hi Drag Practice Bomb (Conventional Usage)
MK-84 Without Thermal Protection
MK-84 Thermally Protected
GBU-10 MK-84 Laser Guided Bomb, With/Without Thermal Protection
MK-83 Blunt Nose Without Thermal Protection
MK-83 Pointed Nose Without Thermal Protection
MK-83 Blunt Nose, Thermally Protected
MK-83 Pointed Nose, Thermally Protected
MK-83 BSU-85 Ballute With Thermal Protection
MK-82 Blunt Nose Without Thermal Protection
MK-82 Pointed Nose Without Thermal Protection
MK-82 Blunt Nose, Thermally Protected
MK-82 Pointed Nose, Thermally Protected
MK-82 SnakeEye Without Thermal Protection
MK-82 SnakeEye, Thermally Protected
MK-82 BSU-86 FIN With Thermal Protection
MK-82 Blunt Nose, BSU-33 FIN with Thermal Protection
MK-82 Pointed Node, BSU-33 FIN with Thermal Protection
GBU-24B/B Laser Guided Bomb
SUU-5003 Training dispenser with BDU-5002 Bombs and/or CRV-7 Rockets Switch in
Single Position
SUU-5003 Training dispenser with BDU-5002 bombs and/or CRV-7 Rockets Switch in
Ripple Position
AGM-65F IR Maverick
AGM-65G IR Maverick
LAU-61 A/A rocket launcher, Switch in Single Position
LAU-61 A/A rocket launcher, Switch in Ripple Position
LAU-68 B/A rocket launcher, Switch in Single Position
LAU-68 B/A rocket launcher, Switch in Ripple Position
LAU-10 D/A rocket launcher, Switch in Single Position
LAU-10 D/A rocket launcher, Switch in Ripple Position
AIM-9M Sidewinder
AIM-9L Sidewinder
AN/ASM-464 AIM-9 Missile Test Set
AIM-7F Sparrow
AIM-7M Sparrow
AIM-7M (H Build) Sparrow
AIM-7P Sparrow
LAU-5003 rocket launcher with RLU-5001/B, 6LB,2.75 in rocket, Switch in Single
Position
LAU-5003 rocket launcher with RLU-5001/B, 6LB,2.75 in rocket, Switch in Ripple
Position
LAU-5003 rocket launcher with RLU-5001/B, 6LB,2.75 in rocket, Switch in Single
Position
LAU-5003 rocket launcher with RLU-5001/B, 6LB,2.75 in rocket, Switch in Ripple
Position
CNU-188 Baggage Container
CR 2007 - 584
PRÉSENCE
GRAPHIQUE
Oui
Oui
Oui
Oui
Non
Non
Non
Non
Oui
Non
Non
Oui
Oui
Oui
Oui
Non
Oui
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
Oui
Oui
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
Non
15
D9
AA
AB
AC
AC5
FLIR
AIM-9 Blue Tube
AIM-120A AMRAAM
AIM-120B AMRAAM
AIM-120C AMRAAM
AIM-120C5 AMRAAM
Forward Looking Infrared
Non
Non
Non
Non
Non
Non
D’après les essais effectués, seulement 12 des 55 armements s’affichent de façon
graphique. En plus, le même modèle sert plusieurs fois et lors du lancement d’un de
ces objets, il n’y a aucune représentation graphique du largage ou de la destruction de
l’arme, car les trajectoires des missiles et des bombes ne sont pas encore simulées.
Les modèles d'armes comprennent seulement la logique avant le lancement. De plus,
comme notre ASPB est une version non classifiée, alors certaines parties des modèles
d’arme sont manquantes. Aussi, même si le simulateur indique une quantité de zéro,
la représentation graphique des armements sur les stations de l’avion est toujours
présente. Noter que quelques règles s’appliquent lorsqu’on veut modifier la
configuration des armes. Il faut que l’indicateur weight-on-wheel soit à « ON » et que
les Landing Gear soient descendus. Les stations 4 et 6 sont initialisées seulement au
démarrage, donc le SMS devrait être éteint avant le chargement des armes et ensuite
redémarrer. Finalement, la section Store Loading de l’API ne permet pas de récupérer
de l’information sur l’état, la position, l’orientation, etc. des armements. Pour avoir de
l’information, il faudrait considérer les armements comme une entité HLA au lieu
d’utiliser la section Store Loading.
La section AIM-9 de l’API sert essentiellement à modifier des paramètres avant le
lancement de ce dernier et non à le contrôler durant son vol. L’équipe du SESC s’en
sert principalement pour envoyer des messages au MC et ainsi tester l’Operational
Flight Program (OFP). L’OFP se définie comme étant les logiciels des systèmes
avioniques embarqués.
Il existe d’autres sections à l’API quelque peu nébuleuses sur leur utilité.
2.3 Autres informations
Dans
les
dossiers
de
l’ASPB
plus
précisément
dans
« ASPB
path\Support\MuxDefinitions », on retrouve des fichiers définissant les messages
1553. Ces messages sont aussi accessibles via l’interface graphique de l’ASPB avec le
panneau Mux Control Panel. Le tableau 5 donne un exemple de message. Ce message
semble donner la vitesse de l’avion. Il est le mot #1 des 11 mots qui complète le
message. La valeur contenue dans le message est 6.25E-002 avec comme unité des
nœuds. Cette valeur semble être transférée du Air Data Computer (ADC) vers le
Mission Computer (MC). Cela dit, l’interaction de ce message avec l’ASPB n’est pas
documentée. Par contre, grâce à l’étiquette, il est possible de récupérer ces données
pour les utiliser dans du code (Tableau 8). Dans le projet C++ High Level Function
(HLF), on retrouve des exemples sur la façon d’utiliser ces étiquettes. Dans l’API,
c’est la section I/O Signal Control qui permet de jouer avec ces différents messages
1553.
Malheureusement, certains des messages 1553 ne semblent pas être
complètement implantés. Par exemple, plusieurs messages font référence à la
16
CR 2007 - 584
présence d’un AIM-9, mais même si ce dernier est présent sur l’avion la valeur de ces
messages reste toujours à zéro.
Tableau 5. Exemple d’un message 1553 dans le fichier de configuration de l’ASPB
MOT #
ÉTIQUETTE
/
DESCRIPTION
UNITÉ
DE
VERS
KNOTS
ADC
MC
VALEUR
NOMBRE DE
MOT
IATASP
TRUE AIRSPEED
#1/11
6.2500000000000000E002
Tableau 6. Exemple de code utilisant un message 1553 des fichiers de configuration de l’ASPB
GS_AVMUX_LABEL_ENG(IAIASP);
IAIASP.getValue();
if ( 80.0 < IAIASP ) {}
La valeur contenue dans IAIASP est mise à jour seulement à l’appel de la fonction getValue()
Les différents systèmes émulés de l’ASPB communiquent grâce à une simulation du
1553/1760 sur la couche IP. À l’interne, les modèles communiquent entre eux grâce
au protocole (COM Component Object Model) de Windows. D’après les informations
reçues, pour la communication avec un ordinateur distant, les messages 1553/1760
sont modifiés pour être broadcastés sur un réseau IP et les réponses (status word)
attendues par le Bus Controller sont comblées à l’interne (avec un « Wrapper »). Cette
implantation est dû au fait que la réception d’un status word doit se faire dans un délai
plus court que la latence du protocole IP. Cette petite manipulation implique que les
messages 1553 envoyés sur le réseau Ethernet sont toujours considérés comme valides.
D’autres informations expliquaient comment modifier l’ASPB afin de simuler, par
exemple, le Stores Management System (SMS) sur un autre ordinateur (voir section B
en annexe), mais ces manipulations impliquaient des fichiers inexistants sur notre
installation de l’ASPB. De la documentation et information supplémentaire sur le
1553overIP pourrait nous éclairer sur son utilisation et implantation possible.
Un CD nommé « MCTS Tools and Demo Project 3.0.4 » comprend une version de
l’API « StandAlone ». Cette version permet de développer avec l’API sans
l’installation complète de l’ASPB. Le projet HLF s’y retrouve aussi. Ce projet a pour
but de fournir des fonctions de haut niveau et pour uniformiser l’utilisation de l’ASPB
lors de tests sur l’Operational Flight Program (OFP). Le CD contient aussi certains
outils qui démontrent l’utilité de l’API et du projet HLF.
Un autre CD appelé « MCTS 3.0.1 Essentials » comporte certains pilotes et mise à
jour de Windows nécessaires pour le bon fonctionnement du Simulateur. De plus,
CR 2007 - 584
17
certains documents donnent de l’information sur le Cougar HOTAS et une façon de le
calibrer.
L’ASPB supporte le protocole de simulation distribué HLA (DMSO RTI-NG 1.3v6).
Par contre, aucune documentation à ce sujet n’est disponible. Les classes
CfederateIdentifier et CEntityIdentifier dans la section Synthetic Environment de
l’API sont probablement reliées à l’utilisation du HLA dans l’ASPB. D’après les
informations, en activant le HLA broadcast et en utilisant le HLA RTI, il serait
possible d’instaurer des états aux entités et ainsi connaître par exemple le moment où
une entité a été atteinte par un projectile. La procédure pour la configuration de
l’ASPB est expliquée dans la section C de l’annexe.
2.4 Manipulations possibles
Pour larguer un AIM-9 miré sur une cible avec le simulateur, il faut :
1.
2.
3.
4.
5.
Configurer l’avion dans le Stores Loading avec un AIM-9
Monter le landing Gear dans le Landing Gear Panel
Positionner le bouton Master à Arm dans le Master Arm Panel
Choisir A/A (Air-to-air) dans le Master Arm Panel
Utiliser le bouton Air-to-Air Weapon Select (#18) du HOTAS pour choisir le
missile AIM-9
6. Choisir le mode AACQ (Auto acquisition) (HOTAS bouton #12) pour mirer
automatiquement sur la cible. (Si aucune détection ne se produit, bouger le
« seeker » avec le bouton ANT ELEV)
7. Finalement, bouton fire (Gun/Missile Trigger, #1)
18
CR 2007 - 584
Auto acquisition
Figure 8. Mode auto acquisition avant la détection d’une cible
Figure 9. Configuration de l’ASPB avec un AIM-9 miré sur une cible
CR 2007 - 584
19
Utiliser le FLIR :
1.
2.
3.
4.
5.
Configurer l’avion avec un FLIR.
Monter le landing Gear dans le Landing Gear Panel.
Mettre le FLIR à ON dans le Sensor Control Panel.
Dans le menu TAC d’un display, choisir FLIR en haut à gauche.
Un « cooled down » de 6 minutes s’effectue avant que le cône rouge s’affiche
dans le Flight View. Lorsque le FLIR est prêt, les lettres OPR s’affichent dans
le coin en haut à gauche dans un des Displays.
6. Pour bouger manuellement le FLIR bouger le Sensor Control switch à gauche
(bouton #14), ensuite utiliser le TDC pour déplacer le cône rouge.
*Noter que dans la version 3.0.1 le FLIR peut être utilisé seulement pour suivre
des ennemis au sol dans la région de l’aéroport de Cold Lake.
Pour larguer une GBU24 manuellement :
1. Configurer l’avion avec un GBU24.
2. Dans le menu TAC d’un des displays, choisir Stores à gauche, ensuite GB24
en haut à gauche.
3. Cliquer sur mode à gauche et choisir MAN pour manuel.
4. Monter le landing Gear dans le Landing Gear Panel.
5. Positionner le bouton Master à Arm dans le Master Arm Panel.
6. Choisir A/G (Air-to-Ground) dans le Master Arm Panel.
7. Lancer la bombe avec le bouton Weapon Release (#2).
*Noter que le radar peut prendre un certain temps avant d’être opérationnel.
Pour larguer une GBU24 automatique avec le radar :
1. Configurer l’avion avec un GBU24.
2. Dans le menu TAC d’un des displays choisir Stores à gauche, ensuite GB24 en
haut à gauche.
3. Dans le menu MFUZ à gauche, choisir N/T.
4. Monter le landing Gear dans le Landing Gear Panel.
5. Positionner le bouton Master à Arm dans le Master Arm Panel.
6. Choisir A/G (Air-to-Ground) dans le Master Arm Panel.
7. Activer le radar avec le bouton Sensor Control (#12) du HOTAS.
8. Utiliser le TDC (#19 sur le Throttle) pour déplacer le curseur du radar et
choisir une cible (ou automatiquement avec le bouton Sensor Control (#12) du
HOTAS)
9. Une ligne verticale (ASL) apparaît sur le HUD. Se centrer sur cette ligne.
10. Tenir le bouton Weapon Release (#2).
11. Suivre une trajectoire droite ou montante pour que le décompte de l’étiquette
REL décroisse jusqu’à 0.
12. À 0 le lancement du GBU24 se fera automatiquement. Lorsque que la ligne
ASL clignotera, cela signifiera que la procédure de lancement est terminée et
que le bouton Weapon Release peut être relâché.
20
CR 2007 - 584
Ligne ASL
Curseur TDC
Figure 10. Configuration de l’ASPB avec un GBU24 en mode automatique
D’autres manipulations intéressantes
1) Pour activer le radar : Dans un Display (L/RDDI, HIS), cliquer Menu (en bas
au centre), RDR ATTK (à gauche en haut)
2) Pour afficher les stores : Menu, Stores (à gauche en haut)
Noter que lorsque l’ASPB vient de démarrer, le radar et le menu de Stores peuvent
prendre environ 5 à 6 minutes avant d’être opérationnels.
Les différents numéros de boutons sont représentés graphiquement dans l’aide client
de l’ASPB (ou voir le fichier MCTS_Client_Help.chm)
2.5 HOTAS Cougar
Le HOTAS pour hands on throttle-and-stick, est un joystick similaire à celui d’un F-16
et il a été acheté de la compagnie « Extreme Gaming Device ». Pour l’utiliser avec
l’ASPB, il faut installer les pilotes et logiciels fournis sur le CD d’installation.
CR 2007 - 584
21
Ensuite, pour le configurer tel qu’expliqué dans l’aide de l’ASPB, il faut modifier
certains axes. Finalement, une calibration du joystick est nécessaire pour que les
boutons soient bien ajustés. Un document situé sur l’ordinateur de l’ASPB et en
annexe donne des captures d’écran de toutes les configurations qui sont à modifier.
L’installation du Cougar semble avoir été fait seulement sur un port USB, donc il est
important de toujours brancher le HOTAS dans le même port USB, sinon un message
d’erreur « Device not Found » apparaît.
Pour une raison quelconque, si les configurations du HOTAS semblent avoir changés :
1. Ouvrer le programme « HOTAS Cougar Control Panel » (Figure 11)
2. Charger le profil ASPB.tmc
3. S’assurer que la configuration soit à « Manual calibration » dans la section du
bas
4. Appliquer les changements avec « Apply »
Figure 11. Panneau de configuration du HOTAS
Noter que le bouton TRIM dans le panneau « HOTAS control » de l’ASPB ne bouge
pas, mais cela n’empêche pas son bon fonctionnement durant le vol. Ce problème est
22
CR 2007 - 584
connu par le SESC. Aussi, des configurations alternatives sont disponibles sur le CD
de l’ASPB intitulé « MCTS 3.0.1 Essentials ».
2.6 Développement en cours de l’ASPB par le SESC
Présentement, l’ASPB est toujours sous développement puisqu’il n’est pas un produit
fini.
L’équipe de SESC à Mirabel améliore l’ASPB pour qu’il supporte
l’interconnexion d’un vrai réseau 1553/1760. D’après les informations recueillies, la
prochaine version de l’ASPB qui supportera le protocole 1553/1760(mux only)
possédera une carte 1553/1760 avec 8 canaux (possiblement la carte condor
EPMC1553). Ainsi, tous les bus du CF-18 seront accessibles. L’Armament bus est
celui qui utilise le 1760. Ne pas oublier que pour utiliser tous les canaux en même
temps, il faudra une série de câbles coaxiaux 1553 pour chaque canal. Aussi, comme
le 1760 est utilisée « mux only », alors seulement les lignes MUX A et B (bus de
données) seront utilisés. Ces deux lignes sont les mêmes que ceux du protocole 1553
et donc les mêmes câbles peuvent être utilisés. Petit rappel, la ligne B est la
redondance de la ligne A. Grâce à ces améliorations, il sera enfin possible de
connecter l’ASPB sur un vrai réseau 1553 et ainsi, communiquer avec le MPCU.
2.7 Blocs Simulink de l’API : ASPBLibrairy
Pour permettre l’utilisation de l’API par les utilisateurs de Simulink, plusieurs blocs
ont été développés grâce à des s-function. En gros, les blocs permettent de créer de
nouvelles entités, de modifier ou récupérer l’état (orientation, position, vélocité,
accélération, etc.) du CF-18 ou d’une entité. D’autres peuvent modifier ou récupérer
des valeurs atmosphériques et environnementales de l’ASPB (et encore plus). Tous
ces blocs sont regroupés sous la librairie ASPBLibrairy.mdl. La section E de l’annexe
décrit en détail tous les blocs contenus dans cette librairie, tous les fichiers qui y sont
reliés et la procédure de compilation des s-function. Noter que pour utiliser cette
librairie, il faut que l’émulateur du CF-18 soit installé et ouvert sur le même
ordinateur.
2.8 Interfaçage avec des scénarios Simulink GGM
Même si l’API GsAPI ne permet pas une interaction immédiate avec le SMS pour
communiquer avec les modèles d’armes, certaines fonctionnalités permettent quand
même d’avoir une utilisation de base de l’ASPB avec des scénarios Simulink. Ainsi,
les scénarios GGMBaseLine.mdl et MultiGGMBaseLine.mdl ont été modifiés pour
interagir avec l’ASPB. Les sections suivantes expliquent les modifications apportées.
Le premier modèle comprend un CF-18 qui tire un missile sur une cible. Le second
répète la même chose, mais deux missiles sont lancés.
Deux scénarios GGMBaseLineASPBValidation.mdl et GGMBaseLineValidation.mdl
ont été créés pour valider l’utilisation de la physique de l’ASPB dans les modèles
scénario.
CR 2007 - 584
23
Pour plus de renseignements sur les scénarios Simulink en général, voir les fichiers
suivants : « MIST Specification - Master document.pdf » et « Tutorial for MuSiM and
MSTARS.ppt ». Ces derniers sont fournis avec l’installation de MstarsDRDC. Pour
plus de renseignements sur la librairie ASPBLibrairy voir « ASPB Library.doc » dans
la base de données MS Visual Source Safe WESDATABASE sous
$/Avionics/APSB/SimulinkLibrary ou en annexe. Pour plus d’information sur l’ASPB
voir l’aide de l’ASPB : « GsApiV1.chm » et « MCTS_Client_Help.chm » et
optionnellement le PDF « CF19C_Greybook.pdf ».
2.8.1 Modification du fichier GGMBaseLine
Le scénario GGMBaseLine a été modifié pour l’interfacer avec l’émulateur
du CF-18 (ASPB). Les modifications ont pour but d’utiliser le CF-18 avec un
pilote qui mire et déclenche le lancement d’un missile sur une cible contrôlé
par Simulink. Lorsque le pilote tire, un signal déclenche les calculs
physiques dans Simulink de la trajectoire d’un missile. Ce dernier n’est pas
illustré dans l’ASPB, car aucun modèle graphique n’existe pour le moment.
Pour visualiser le scénario au complet, l’outil Replay démarre à la fin du
scénario permettant de voir l’interaction du missile dans le scénario.
En général, les modifications ont été de:
1. Remplacer la cinématique du CF-18 par celle de l’ASPB en allant
récupérer l’état du CF-18 dans l’émulateur. L’état se définit comme
étant, la position, la vélocité, l’accélération, la vélocité angulaire et
l’orientation (angle d’Euler).
2. Afficher la cible dans l’ASPB en créant une entité dans l’ASPB et en
fournissant la position et l’orientation.
3. Modifier l’événement qui active le signal triggerLaunch. Ce dernier
est maintenant activé lorsqu’un missile quitte une station du CF-18
(lorsque la quantité affichée sur un des écrans de bord diminue).
24
CR 2007 - 584
Figure 12. Intérieur du bloc CF-18 du scénario GGMBaseLineASPB
Figure 13. Bloc affichant la cible dans l’ASPB
Dans la figure 12, les blocs CF-18_ASPB_Kinematics et ASPB_Simple_FCS
(sous le bloc CF-18) implantent les modifications 1 et 2 énumérées plus haut
et le bloc ASPBOutputTarget (figure 13) réfère à la modification 3. Sous ces
blocs, des blocs de la librairie ASPBLibrairy ont été utilisés pour récupérer
l’état du CF-18 ou modifier l’état de la cible. D’autres ont servis à convertir
plusieurs données, car l’ASPB n’utilise pas le système international. Certains
ont été créés sur mesure pour des fonctionnalités spécifiques.
CR 2007 - 584
25
Figure 14. Intérieur du bloc de la cinématique du CF-18 dans le scénario GGMBaseLineASPB
Figure 15. Grossissement de l’intérieur du bloc de cinématique
La figure 14 représente la modification apportée au bloc de cinématique. Le
bloc à l’extrême gauche (SetVelocityAndPosition) permet de placer le CF-18
26
CR 2007 - 584
dans une position, orientation et vélocité initiales. Ce bloc est une s-function
faite sur mesure pour convertir et appliquer les valeurs reçues en paramètre
une seule fois et au début de la simulation. Pour se convertir aux unités de
l’ASPB, la vélocité a été convertie de m/s à ft/s grâce à des fonctions de l’API
GsAPI.
La figure 15 est un grossissement de la cinématique utilisée durant le
déroulement du scénario. Le bloc Get Flight Control récupère plusieurs
données sur le CF-18 (l’accélération vectorielle, l’orientation, la vélocité
angulaire, la position et la vélocité) qui sont modifiées grâce à des blocs de
conversion pour être compatibles avec le scénario Simulink. Ensuite, elles
sont regroupées dans le signal « Dynamic_State » qui comprend dans l’ordre
les signaux suivants : position, vélocité, accélération, vélocité angulaire,
Matrice de transformation.
Pour la vélocité et l’accélération, il a fallu modifier les pieds en mètre et pour
la vélocité angulaire, les degrés en radians. Comme l’ASPB utilise un
système Geodetic pour la position, celle-ci a dû être convertie au système
NED grâce au bloc « Earth transformation functions ». Pour ce faire, un
point d’origine geodetic devait être défini. Le point utilisé est la position du
CF-18 lors de l’ouverture de l’ASPB, ce qui est au début de la piste
d’atterrissage de l’aéroport de Cold Lake. Noter que la composante NED
résultante est retransformée pour passer de l’unité de pied en mètre.
Finalement, pour trouver la matrice de transformation, le bloc Euler2TM de
la librairie MstartsUtilities a été utilisé avec comme entrée l’orientation du
CF-18. Par contre, il faut remarquer qu’il a fallu préalablement convertir les
degrés en radians et échanger la 1re composante avec la 3e composante du
vecteur d’orientation (bloc Euler123To321) pour avoir le bon vecteur d’entré
dans le bloc Euler2Tm. Le tableau 7 résume les conversions effectuées.
Tableau 7. Conversions nécessaires pour utiliser la cinématique de l’ASPB dans un scénario Simulink
SIGNAUX DE L’ASPB
CONVERSION
COMPOSANTE DU SIGNAL
DYNAMIC_STATE
Acceleration Vector
ft/s² Æ m/s²
3. Accélération
Attitude
deg Æ rad,
5. Matrice de transformation
[roll, pitch, head] Æ [head, pitch, roll],
Euler Æ Matrices de transformation
Body angular velocity
deg Æ rad
4. Vélocité angulaire
Location
Geodetic*Æ NED,
1. Position
Velocity vector
ft/s Æ m/s
ft Æ m
2. Vélocité
*Origine geodetic utilisée : [54.39161, -110.270541, 1757.05214] [longitude, latitude, altitude]
Dans l’ASPB deux modèles représentant la terre sont disponibles : WGS84 et
FLAT. Le modèle WGS84 utilise la longitude, latitude et altitude, tandis que
le FLAT devrait normalement utiliser des coordonnées x, y, z. Par contre,
CR 2007 - 584
27
dans l’API GsAPI de l’ASPB seulement une fonction est disponible et elle
retourne la longitude, latitude et altitude. Donc, si ultérieurement, la fonction
était disponible dans l’API, il serait mieux d’utiliser le modèle FLAT, car la
transformation du système geodetic au système NED est sûrement une
approximation.
Figure 16. Intérieur du bloc activant l’événement LaunchTrigger de GGMBaseLineASPB
La figure 16 montre le bloc StoreLaunched (sous F-18\ASPB_Simple_FCS\
ASPBLaunchLogic) qui active le signal LaunchTrigger. Ce bloc est une
autre s-function codée sur mesure pour détecter le lancement d’un missile.
En réalité, toutes les stations d’armement sont vérifiées et si la quantité d’une
station diminue, alors le signal en question est activé. En paramètre, il faut
spécifier le nombre d’armes utilisées pour ajuster correctement la dimension
de la sortie.
Figure 17. Intérieur du bloc affichant la cible dans l’ASPB
28
CR 2007 - 584
La figure 17 illustre l’intérieur du bloc ASPBOutputTarget permettant
l’affichage graphique d’un avion dans l’ASPB pour qu’un pilote puisse mirer
et lancer un missile sur une cible. Il a fallu, comme dans le cas de la
cinématique du CF-18, convertir les données du scénario en format
compatible pour l’ASPB (Tableau 8). Par contre, lors de la représentation
graphique seulement deux signaux sont nécessaires : position et orientation.
Ces derniers sont récupérés à partir des composantes du signal
« BodyStateE ».
Tableau 8. Conversions nécessaires pour l’affichage d’une entité dans l’ASPB à partir d’un scénario Simulink
COMPOSANTE DU SIGNAL
DYNAMIC_STATE
CONVERSION
Matrices de transformation Æ Euler,
4. Matrice de transformation
SIGNAUX DE L’ASPB
Attitude
[Roll, pitch, head] Æ [head, pitch, roll],
rad Æ deg
m Æ ft,
1. Position
Location
NEDÆ Geodetic*
*Origine geodetic utilisée : [54.39161, -110.270541, 1757.05214] [longitude, latitude, altitude]
Problème :
•
Lors du lancement du missile, sa trajectoire de départ semble
erratique. Pour bien voir le phénomène, utiliser Replay et fixer la
caméra sur le missile.
Amélioration possible :
•
•
•
Utiliser un système WGS84 dans tout le modèle Simulink ou trouver
le moyen d’exploiter le modèle FLAT de l’ASPB.
Déterminer avec les messages 1553 du lancement du missile au lieu
de regarder la quantité.
Regarder les messages 1553 disponibles et voir quelles étapes de
lancement pourraient être ajoutées dans le modèle (exemple:
détection d’une cible par le radar)
2.8.2 Modification du fichier MultiGGM
En gros, les modifications nécessaires à ce fichier ont été les mêmes que ceux de
GGMBaseLine. Par contre, comme le modèle du CF-18 est un peu plus complexe
(Figure 18), le bloc détectant le lancement d’un missile dans l’ASPB a été positionné à
un autre endroit.
CR 2007 - 584
29
Figure 18. Intérieur du bloc F-18 du scénario MultiGGM
Figure 19. Grossissement de l’intérieur du bloc CF-18 du scénario MultiGGM
Dans la figure 19, le bloc StoreLaunched envoie le signal indiquant le tir d’un missile
dans le bloc du Flight Control System (FCS). Après le passage de plusieurs soussystèmes, le signal est utilisé à l’intérieur du bloc Subsystem illustré à la figure 20. En
bas à gauche, un index représentant le missile tiré est utilisé pour récupérer la bonne
30
CR 2007 - 584
donnée du vecteur envoyé par le bloc StoreLaunched.
Dans le scénario
GGMBaseLine, le signal activant le triggerlaunched avait été remplacé par
storeLaunched, mais ici les deux ont été couplés avec l’opérateur logique ET.
Figure 20. Bloc activant l’événement triggerLaunch de MultiGGM
Problème :
•
Même que pour le modèle GGMBaseLineASPB.
•
Après le premier pas de temps, les missiles sont initialisés avec un
angle de 90 degrés par rapport à l’avion. Par contre, si l’orientation
du CF-18 est à [roll, pitch, heading] = [0, 0, 0], alors le premier
missile est bien initialisé (même orientation que l’avion), mais lors du
lancement du deuxième missile, ce dernier se remet à 90 degrés par
rapport au CF-18. Si les données fournies par l’ASPB sont correctes,
le problème peut provenir des blocs InitialLchTme et/ou Adjust
Launcher
Offset
dans
« MultiGGMASPB/
F-18
/
FCSMultiWpnTgtAssignment/ FCSMultiWpnTgtAssignment ».
Amélioration possible :
•
Même que pour le modèle GGMBaseLineASPB
2.8.3 Validation de la physique de l’ASPB
Le scénario GGMBaseLineASPBValidation comprend le bloc de cinématique
de l’ASPB comme dans GGMBaseLineASPB, mais le bloc pour l’activation
du signal triggerlaunched est un peu différent. Maintenant, l’utilisateur peut,
via le masque du CF-18, choisir s’il veut déclencher le lancement du missile
CR 2007 - 584
31
avec l’ASPB immédiatement ou après un certain temps. Ainsi, la seule
différence entre le scénario ASPB et le GGMBaseLine est la physique de
l’ASPB qui permet de faire une validation plus juste.
GGMBaseLineValidation est le même scénario que GGMBaseLine, mais
avec des valeurs initiales semblables à GGMBaseLineASPBValidation pour
effectuer une simulation sans la physique de l’ASPB et vérifier que le résultat
du lancement du missile est correct.
Dans les deux scénarios, l’avion est mis dans un état (Position, orientation et
vélocité) identique (sauf la position en z) pour suivre une trajectoire similaire.
De plus, le lancement du missile se fait au même moment et dans un temps
très court minimisant l’écart entre les trajectoires des CF-18. La cible est
identique dans les deux cas. Donc, on roule GGMBaseLineASPBValidation
et comme la physique de l’ASPB a tendance à faire diminuer l’altitude de
l’avion, on note la valeur (position en z) à laquelle le missile est lancé. Cette
dernière est ajoutée dans le scénario GGMBaseLineValidation (position en z
du CF-18) qui est ensuite démarré.
Les vidéos Replay montrent que les simulations se déroulent de façon très
similaire. De plus, la ressemblance des courbes dans les graphiques cidessous prouve la validation. Une différence peut être perçue au niveau de
l’axe Z, car le CF-18 de l’ASPB a tendance à piquer du nez et ainsi faire
décoller le missile un peu vers le bas. On peut remarquer dans les deux cas
que le missile ne perd pas de vue la cible (OnBoarsSensorValidData).
32
CR 2007 - 584
Figure 21. Comparaison des trajectoires entre GGMBaseLineASPBValidation(gauche) et GGMBaseLineValidation(droite)
CR 2007 - 584
33
Figure 22. Comparaison du LOS entre GGMBaseLineASPBValidation(gauche) et
GGMBaseLineValidation(droite)
34
CR 2007 - 584
Figure 23. Comparaison de l’accélération entre GGMBaseLineASPBValidation(gauche) et
GGMBaseLineValidation(droite)
CR 2007 - 584
35
3.
PC/104
Les PC/104, un standard, sont de petites cartes qui incorporent en quelque sorte un
ordinateur presque complet. Ils sont utilisés surtout pour des systèmes embarqués
puisqu’ils sont de petite taille. Ces cartes sont faites de sorte qu’ils s’emboîtent les
unes sur les autres maximisant l’espace. Il existe quelques variantes des PC104, voici
une liste avec une petite description (voir aussi figure 24) :

PC/104 Carte comprennent un bus ISA 104-pins
PC/104+: Carte comprenant un bus ISA 104-pins et un bus PCI 120 pins
PCI-104: Carte comprenant seulement un bus PCI 120 pins
Trois PC/104 ont été testés pour vérifier leur état et leur compatibilité 1553.
Le Pentium 4 Cool RoadRunner 4 semble brisé: les LED indiquant le « LIVE » et
POWER GOOD » ne s’allume pas et même avec le changement de la barrette de mémoire
rien ne s’affiche à l’écran.
Figure 24. Carte PC/104+ avec bus ISA et PCI
36
CR 2007 - 584
Le 486 MZ104 fonctionne bien. Il est utilisé avec une carte d’extension ISA pour y
insérer une carte vidéo TRIDENT et ainsi permettre la connexion d’un écran VGA.
Ce PC104 est compatible avec l’OS xPC de Matlab/Simulink. Dans les configurations
de l’outil xPC Explorer, il faut absolument choisir l’option « Target PC is a 386/486 ».
La communication entre Host et Target se fait facilement avec le port Série. Pour la
communication via une carte réseau, il faut absolument affecter un IRQ et une
adresse à la carte Ethernet. Normalement cette manipulation doit se faire dans le bios,
mais ce PC104 n’offre pas ces options. Par contre, un outil situé sur le DISK-ONCHIP dans le dossier « réseau » permet de modifier l’IRQ et l’adresse de la carte
réseau, mais cela n’a pas été vérifié. Pour activer le DISK-ON-CHIP, voir le manuel
de l’utilisateur du MZ104.
Le Pentium 266MHz de Kontron semble bien fonctionner, mais du fait qu’il manquait
des adapteurs pour connecter un lecteur disquette, l’OS xPC Target n’a pas été testé.
Voici les adapteurs qui seraient utiles :
•
PS/2-Keyboard adapter for MOPS (8pin to PS/2 connector):
http://us.kontron.com/index.php?id=226&cat=622&productid=449&source=S
earchengine (Keyboard PS/2)
•
Cable to USB-Port from 4pin header:
earchengine (USB)
•
standard floppy drive 3.5 to flatfoil connector :
earchengine (floppy 3.5’’)
•
IDE adapter cable for 44½ pin 2 1/2" Hard Disk to 40 pin 3,5" HarddiskL:
earchengine
Dans un premier temps, les PC104 ont été testés dans le but de les connecter au réseau
1553 en utilisant le système d’exploitation xPC Target. Par contre, aucun PC104 n’est
compatible 1553, donc il faudrait acheter des cartes PC104-1553 pour les emboîter sur
le MZ104 ou le Pentium 266MHz. Noter que le Cool RoadRunner ne possède pas de
bus ISA, mais seulement un bus PCI.
La seconde idée était de simuler le 1553 par le réseau Ethernet entre deux PC104 ou
bien entre un ordinateur et un PC104. Malheureusement, une connaissance très
approfondie du 1553 était nécessaire et le temps de développement aurait été très long.
Pour contrer ces problèmes, la technologie Ipo1553 pour IP over 1553 créée par
OnBoard software Inc. pourrait être utilisée. Une seconde possibilité serait de regarder
l’implantation du 1553 over IP de l’équipe de SESC.
CR 2007 - 584
37
3.1 Carte PC/104 compatible 1553
Plusieurs compagnies vendent des cartes PC104 compatibles 1553. DDC (Data
Device corp) et GE ont fait parvenir des estimés. Les produits de DDC étaient
sensiblement moins coûteux. Par contre, leurs cartes ne sont pas toujours compatibles
avec toutes les versions de VxWorks et autres systèmes d’exploitation. Noter que
DDC donne la possibilité d’essayer leur produit sur demande. Pour les produits de
GE, la compatibilité avec les OS ne semble pas un problème. De plus, leurs cartes
possèdent un peu plus de mémoire, et ils sont utilisables avec Simulink/xPC Target.
Voici les cartes:
Tableau 9. Carte PC104-1553 de Data Device Corp.
TYPE
DESCRIPTION
PART #
PRIX
COMPATIBILITÉ
PC104
RT seulement
BU-65567C1-300
3163.00
VxWorks 5.0
PC104
Single fonction
BU-65568C1-300
3012.00
VxWorks 5.0
PC104+
Single fonction
BU-65578C
--
VxWorks 6.x
Permets l’essai de leur produit
Tableau 10. Carte PC104-1553 de Condor
CONNECTEUR
38
DESCRIPTION
PART #
PRIX
PC104
Multifonction
Q104-1553-1M
6825.00$
PC104
Single fonction
Q104-1553-1S
3215.00$
PC104+
Multifonction
Q104-1553-1M-P
7225.00$
PC104+
Single fonction
Q104-1553-1S-P
3615.00$
CR 2007 - 584
4.
MPCU
Le MPCU est une boîte qui contient une carte VME backplane permettant d’y insérer
plusieurs cartes single board computer (SBC) compatibles VME. Dans le futur, ces
cartes permettront de regrouper plusieurs composantes d’un CF-18 en une seule boîte.
De plus, elle permettra aussi l’ajout de nouvelles composantes pour permettre de
nouvelles fonctionnalités au CF-18.
De notre côté, seulement une carte est disponible (en livraison). Cette SBC est une
carte comprenant un processeur PowerPC 1.0GHz, 1 port Ethernet (10/100 BASE-T),
2 ports Gigabit (Gbe), 2 interfaces serial ATA, un canal 1553 et plus. D’après la
documentation, elle supporterait aussi le 1760 sur le même canal 1553. Il est à noter
que le port Gbe est aussi compatible avec les anciennes versions des ports Ethernet
(10/100 BASE-T). Les ports Ethernet permettraient la communication réseau avec
d’autres ordinateurs et aussi la communication avec un Host, si le système
d’exploitation VxWorks y est installé. Des disques durs pourraient être installés grâce
au serial ATA.
Normalement, le système d’exploitation Vxworks devait y être installé pour utiliser les
propriétés 1553 de la carte. Un API C, fournit à part, permettrait la programmation de
message 1553. De façon certaine, il faudrait utiliser cet API dans des S-function pour
interfacer les propriétés 1553 de la carte avec les scénarios Simulink. De plus, il
faudra vérifier avec l’équipe de Mirabel, les différents messages 1553 à utiliser. Une
fois installé sur le réseau 1553 avec l’ASPB, le MPCU pourra simuler de façon
matérielle une des boîtes simulées de façon logicielle par l’ASPB. De plus, grâce à la
compatibilité 1760, il pourra éventuellement simuler un modèle d’arme et
communiquer avec le SMS de l’ASPB.
4.1 VxWorks
Ce système d’exploitation est en Temps réel et distribué par WindRiver. La version
achetée pour le projet est VxWorks5.5.1/Tornado 2.2.1. Cette version avait été
choisie, entre autres, pour être compatible avec l’outil RTW de Matlab 2006a-2007a.
Il est à noter que pour les versions plus récentes, Tornado est devenu WorkBench.
Tornado est l’outil graphique permettant la programmation/compilation du code
destiné à VxWorks. Normalement, Tornado est installé sur un ordinateur Host et le
système d’exploitation est sur le Target. Notre version comprend aussi un simulateur
de Vxworks nommée VxSim. Ce dernier permet de programmer et de tester notre
code sans utiliser de Target. Par contre, VxSim simule seulement le système
d’exploitation, par conséquent, les particularités du hardware ne sont pas prises en
compte. De plus, notre version du simulateur ne comprend pas la partie réseautique,
donc il est impossible de simuler la communication Ethernet entre plusieurs Target.
CR 2007 - 584
39
5.
Utilisations possibles de bancs d’essais
Beaucoup de matériel et logiciels sont nécessaires pour la réalisation du montage de la
figure 1. En fonction des besoins et du niveau de réalisme à atteindre, plusieurs
variantes de ce montage peuvent être instaurées. Les sections ci-dessous en présentent
quelques-unes. Ces exemples impliquent un modèle d’arme qui normalement
communique avec le Stores Management System (SMS) seulement via l’Armament
Bus (protocole MIL-STD-1760). Dans le cas où le modèle utilisé nécessite la
communication avec d’autres bus du CF-18 comme l’Avionic Bus (AVMUX), alors le
protocole 1553 est utilisé.
5.1 Système sans utilisation directe du MIL-STD-1553/1760
Figure 25. Modèle de bombe et ASPB avec GsAPI
L’ASPB et le scénario Simulink pourraient rouler sur le même ordinateur (Figure 25).
L’API GsAPI est facilement intégrable dans des s-function pour utiliser les propriétés
de l’ASPB via des blocs Simulink. Pour l’instant, GsAPI ne permet pas de
communiquer directement avec les différentes composantes émulées/simulées par
l’ASPB. Pour un scénario impliquant une arme, il faudrait être en mesure de
communiquer avec le SMS. Donc, l’API devrait être modifié en conséquence.
40
CR 2007 - 584
Figure 26. Modèle de bombe et ASPB communiquant avec 1553overIP
Les scénarios avec une arme pourraient être sur un autre ordinateur avec un des
systèmes d’exploitation cités sur la figure 26. La communication avec l’ASPB se
ferait via l’implantation du 1760overIP que le SESC a intégré dans l’ASPB. Par
contre, cette implantation n’est pas documentée. D’après les informations reçues, les
messages 1553/1760 sont modifiés pour être broadcastés sur un réseau Ethernet et les
réponses (status word) attendues par le Bus Controller sont comblées à l’interne (avec
un « Wrapper »). Cette implantation découle du fait que la réception d’un status word
doit se faire dans un délai plus court que la latence du protocole IP. Cette petite
manipulation implique que les messages 1553 envoyés sur le réseau Ethernet sont
toujours considérés comme valides. D’autres informations expliquaient comment
modifier l’ASPB afin, par exemple, de simuler le Stores Management System (SMS)
sur un autre ordinateur (voir en annexe), mais ces manipulations impliquaient des
fichiers inexistants sur notre installation de l’ASPB. De la documentation et
renseignement supplémentaires sur le 1553overIP pourraient nous éclairer sur son
utilisation et implantation possible. Donc, dans notre cas, il faudrait que le SMS de
l’ASPB soit en mesure d’envoyer et de recevoir les messages 1760overIP pour
communiquer avec le modèle de bombe simulé sur un autre ordinateur. D’après le
SESC, un montage similaire à la figure 26 utilisant le 1553overIP serait déjà utilisé à
Mirabel. Idéalement, un API du 1553/1760overIP pourrait être rapidement et
facilement implantable dans des s-function pour développer des scénarios avec
Simulink.
Si le même principe est exploité, mais en utilisant le système d’exploitation (OS)
temps réel xPC Target, des pilotes devront être développés pour que des scénarios
CR 2007 - 584
41
Simulink roulant sur xPC Target soient en mesure de communiquer avec le SMS de
l’ASPB grâce au 1553/1760overIP. Encore une fois, il faudrait plus de documentation
sur le 1553/1760overIP pour l’implanter comme driver. Aussi, une petite formation
sur le fonctionnement du xPC Target serait un très bon atout. Alternativement, le
système d’exploitation VxWorks pourrait être utilisé. Les mêmes questions se posent
pour le xPC Target. Une formation sur Tornado/VxWorks améliorerait la productivité
et l’efficacité de la programmation sous ce système. Noter qu’avec ces deux OS, un
troisième ordinateur, nommé Host, avec Windows et Matlab/Simulink/RTW sera
nécessaire pour développer les scénarios Simulink. Une fois terminés, les scénarios
seront téléchargés et démarrés sur l’ordinateur avec VxWorks/xPC Target, nommé
Target.
5.2 Système avec MIL-STD-1553/1760
Figure 27. Modèle de bombe et ASPB communiquant avec 1553/1760
D’après les informations recueillies, la prochaine version de l’ASPB qui supportera le
protocole 1553/1760(mux only) fonctionnera avec une carte 1553/1760 avec 8 canaux
(possiblement la carte condor EPMC1553). Ainsi, tous les bus du CF-18 seront
accessibles. L’Armament Bus (ARMUX) est celui qui utilise le 1760. Ne pas oublier
que pour utiliser tous les canaux en même temps, il faudra une série de câbles
coaxiaux 1553 pour chaque canal. Aussi, comme le 1760 est utilisé « mux only »,
alors seulement les lignes MUX A et B (bus de données) seront utilisées. Ces deux
42
CR 2007 - 584
lignes sont les mêmes que ceux du protocole 1553 et donc les mêmes câbles peuvent
être utilisés. Petit rappel, la ligne B est la redondance le la ligne A.
La figure 27 illustre la possibilité d’utiliser un ordinateur avec une carte compatible
1553/1760 pour communiquer avec l’ASPB. Une carte possible serait la PCI QPCX1553 de Condor qui, d’après le fabricant, posséderait les mêmes fonctionnalités que
celle du (EPMC1553) qui sera possiblement utilisée dans l’ASPB. Son implantation
de façon logicielle demanderait une exploration plus approfondie du produit, mais un
API fourni avec la carte pourrait être une possibilité. Par contre, d’après l’aide de
Matlab, cette carte ne serait pas compatible avec les blocs 1553 développés par
Mathworks.
Présentement, une carte Condor PCI-1553M est disponible, mais celle-ci n’est pas
compatible avec le 1760. Donc cette carte ne pourrait pas être utilisée avec un modèle
d’arme. Par contre, si le modèle d’arme n’utilise pas les particularités du 1760, il
serait possible que la carte PCI-1553M soit utilisée. Cette dernière affirmation
demanderait une vérification avec le SESC et probablement quelques tests avec la
carte. Noter qu’une seule fonctionnalité du 1760 est accessible avec cette carte : le
checksum, ce qui n’est pas suffisant pour la compatibilité 1760. Aussi, si le modèle
n’utilisait pas l’Armament Bus (protocole 1760), mais par exemple, l’Avionics Bus
pour communiquer avec l’ASPB, alors la carte PCI-1553 pourrait être en mesure de
combler la tâche.
Si on supposait que la carte PCI-1553M serait utilisée sous Windows pour
communiquer avec l’ASPB, le logiciel BusTools Visual Analyzer permettrait
d’envoyer des messages 1553, mais il n’est pas directement utilisable avec Simulink.
L’ajout de DLL dans le logiciel permettrait probablement de l’utiliser avec Simulink,
mais de la programmation et des tests seraient nécessaires. De plus, ce logiciel permet
d’insérer le checksum à la fin des messages. Sous xPC Target, des blocs Simulink
implantés par Mathworks existent pour l’utilisation de la carte Condor PCI-1553 dans
Simulink. Par contre, ceux-ci n’implémentent pas la fonctionnalité du checksum. De
plus, la vitesse maximale est très restreinte dû à l’implantation du mécanisme
apériodique de l’API de Condor (voir 1.2.2). Il faudrait vérifier avec le SESC si
l’utilisation de ces blocs serait conforme avec les messages utilisés pour communiquer
avec l’ASPB.
CR 2007 - 584
43
6.
Exemple d’utilisation futur
Figure 28. Modélisation de la communication d’une bombe dans un vrai CF-18
La figure 28 illustre différentes boîtes d’un vrai CF-18 qui sont impliquées dans le
processus de communication avec une bombe. Cette dernière communique avec le
Stores Managements System (SMS) grâce à l’Armament Multiplex bus (ARMUX) qui
utilise le protocole MIL-STD-1760. Le SMS consiste en un Stores Management
Processor (SMP) et de différents Encodeurs/Décodeurs. Ces deux parties utilisent
aussi l’ARMUX pour s’échanger des données. Le Digital Display Indicator (DDI)
permet d’afficher les données nécessaires au pilote pour configurer l’armement s’il y a
lieu.
44
CR 2007 - 584
Figure 29. Modélisation de la communication entre un modèle de bombe et le simulateur du CF-18
La figure 29 démontre l’installation permettant le développement de différents
scénarios implantés dans le MPCU. Noter que le MPCU (Multipurpose Computer
Unit) de la figure 29 est une version de laboratoire comparé à celui de la figure 30.
Donc, un ordinateur comprenant l’ASPB simule plusieurs composantes du CF-18,
entre autres, ceux de la figure 28. L’ASPB communique grâce à un vrai réseau 1553
ou 1760 dépendant du scénario roulant sur le MPCU. Le développement de l’ASPB
pour le rendre compatible avec le MIL-STD-1553 et MIL-STD-1760 se fait par le
SESC à Mirabel.
CR 2007 - 584
45
Figure 30. Modélisation de la communication entre un modèle de bombe et un CF-18
La figure 30 démontre comment un modèle d’arme développé pourrait être testé avec
les composantes d’un vrai CF-18. Le modèle serait chargé sur un MPCU
(Multipurpose Computer Unit) et communiquerait avec les vrais composants du CF-18
pour valider son fonctionnement. Le MPCU utilisé serait une version beaucoup plus
robuste et réaliste comparé à celui de laboratoire (figure 29).
Donc, le développement des scénarios se ferait grâce à un MPCU de laboratoire
communiquant avec un simulateur du CF-18. Ensuite, pour valider correctement le
modèle, ce dernier serait chargé sur un MPCU réel communiquant avec les vrais
composants d’un CF-18.
46
CR 2007 - 584
7.
Conclusion
Le montage de la figure 1 n’a pu être complété pour plusieurs raisons. Premièrement,
le délai de réception de la SBC sur le MPCU n’a pas permis d’installer VxWorks. De
ce fait, sa configuration avec le réseau 1553 et Matlab/Simulink n’a pas pu s’effectuer.
La connexion de l’APSB était carrément impossible, puisque l’implantation du
1553/1760 était faite sur la couche IP et non directement avec du matériel compatible
1553. Les développeurs modifient présentement le simulateur dans cette direction.
L’idée d’utiliser les PC104 a été retardée, puisque la meilleure carte (Cool
RoadRunner) était brisée et en plus, pour la brancher au réseau 1553, il fallait acheter
une carte PC104-1553. Les deux autres PC104 (MZ104 et le FLOPS) eux n’étaient
pas intéressants dû au fait de leur puissance de calcul très faible. Donc, aucunes des
entités du montage n’ont pu être configurées pour une utilisation sur un réseau 1553.
Seulement un ordinateur avec la carte Condor est utilisable avec les composantes du
réseau 1553 reçu. La carte peut être utilisée sous Windows avec Bus Tool Analyzer
ou bien avec xPC Target et un host avec Matlab/Simulink/RTW (en utilisant les blocs
1553 développés par Mathworks). Par contre, il ne faut pas oublier que la carte PCI1553 n’est pas complètement compatible avec le 1760, donc inutilisable avec
l’Armement Bus de l’ASPB.
Vu l’impossibilité d’instaurer le montage prévu, plusieurs autres scénarios considérant
le développement actuel de l’ASPB ont été décrits. Par contre, ces idées demandent
plus de documentation sur l’ASPB, le 1553/1760overIP, les messages 1553 échangés
et possiblement des modifications. Noter que des documents nommés ICD pour
Interface Control Document sembleraient exister pour chaque boîte du CF-18 donnant
des précisions sur les messages 1553 utilisés.
Tout au long de ces embûches, plusieurs autres avenues ont été prises, mais avec plus
ou moins de succès. Pour démontrer le fonctionnement du réseau militaire, on a voulu
faire passer un flux vidéo avec des scénarios Simulink au travers le 1553, mais
seulement un ordinateur compatible 1553 était disponible. Aussi, quelques tests avec
la carte Condor (sous Simulink/xPC Target) ont permis de déterminer que seulement
environ 50 à 100 kbit/sec de bande passante était disponible pour le flux vidéo, ce qui
n’était pas très intéressant. De plus, pour parvenir à faire traverser un flux vidéo, il
aurait fallu interfacer plusieurs outils (vidéo player, encodeur, décodeur, etc.), ce qui
n’était pas une mince tâche.
Pour améliorer l’utilité de l’ASPB, on a voulu l’interfacer avec Matlab/Simulink.
Grâce à l’API plusieurs fonctions ont été implantées pour manipuler les différentes
caractéristiques de l’émulateur. Par contre, seulement deux modèles graphiques
d’entités sont disponibles et la fonctionnalité de simuler la présence d’armement n’est
pas animé graphiquement lors du lancement du projectile. Malgré ces limitations,
deux modèles de simulation ont été modifiés pour les interfacer avec l’ASPB. Ainsi,
un pilote peut utiliser l’ASPB pour mirer et lancer un missile qui est contrôlé
physiquement par Simulink.
CR 2007 - 584
47
Ce projet a impliqué une interaction avec beaucoup de connaissances matérielle et
logicielle, donc la courbe d’apprentissage était assez grande pour parvenir à surmonter
toute l’information nécessaire. De plus, les délais du matériel, plus précisément de la
SBC, et la documentation presque inexistante de l’ASPB ont inévitablement ralenti
l’évolution des travaux. D’après moi, une formation sur le protocole MIL-STD1553/1760, sur tornado/VxWorks et sur l’ASPB permettrait de prendre des décisions
plus éclairées et donc de faire avancer le projet plus rapidement et dans de bonne
direction.
48
CR 2007 - 584
8.
Références
1. Produits 1553
Condor (GE Embbeded) : http://www.gefanucembedded.com/products/family/14/
Data Bus Product: http://www.databusproducts.com/
Ballard Technology: http://www.ballardtech.com
Excalibur System: http://www.mil-1553.com/index.asp
Liste de companies : http ://www.navmar.com/1553cable.htm
2. VME
Liste de compagnies : http ://www.interfacebus.com/COTs_Cards_VME.html
CR 2007 - 584
49
Annexes
A. Informations supplémentaires sur le 1760
The electrical interface is divided in three (3) groups:
1) Signal Lines;
2) Discretes Lines; and
3) Power Line.
The Signal lines include the following signals:
1)
2)
3)
4)
5)
6)
7)
8)
High Bandwidth 1;
High Bandwidth 2;
High Bandwidth 3;
High Bandwidth 4;
MUX A and B;
Low Bandwidth;
Fiber Optic Channel 1; and
Fiber Optic Channel 2.
The MUX A and B signals are the Digital Multiplex Data Interface used in the MILSTD-1760 interfaces. Those signals comply with the MIL-STD-1553, with some
augmentations such as, but not limited to:
1)
2)
3)
4)
5)
6)
Higher signal voltages;
Faster initial response time;
Restricted Message for nuclear weapon;
External Remote terminal assignment;
Message definition and Measurement Unit System; and
Possibility to incorporate a checksum.
In the software perspective, the MIL-STD-1760 MUX A and B are handled as the
MIL-STD-1553 with compliance to the MIL-STD-1760 messages definition.
B. Explication pour utiliser l’ASPB avec un ordinateur
distant
La communication de contrôle entre les modèles se fait par le protocole COMM de
Windows. De ce fait, si un RT est sur un autre ordinateur, par exemple le SMS
Emulator roule sur un autre ordinateur, il faut seulement configurer le fichier suivant
<your path/DCOM Config/MCTS V2 SMS Server> afin qu’il pointe vers l’autre
ordinateur sur le réseau. Plutôt simple. Ensuite, la communication de données 1553
se fait par Ethernet, même sur le même ordinateur. Lorsque le système fonctionne
complètement sur le même ordinateur, microsoft loopback doit être activé afin de
50
CR 2007 - 584
recevoir la communication. Si l’ASPB est branché, tout est broadcasté sur le réseau
Ethernet. Cependant, il faut s’assurer que le fichier suivant est le même sur les deux
ordinateurs (afin d’avoir des sockets correspondants) :
<windows/systeme32/drivers/etc/(hostfile)>.
C. Configuration de l’ASPB avec le HLA
In order to enable the HLA broadcast, you have to modify the following registry key:
HKEY_LOCAL_MACHINE\Software\CAE Inc.\CF-18 MCTS\3.0\SE Distribution
Protocol from LOCAL to HLA
You need to have DMSO RTI-NG 1.3v6 installed
There are many environment variables to setup. I was told that your machine already
has these environment variables configured. But you should verify that the following
steps were done:
Install DMSO Runtime Infrastructure
Supported version: RTI-NG 1.3 v6
Suggested path : C:\Program Files\DMSO\RTI1.3NG-V6
Add the following environment variables:
RTI_HOME
** the RTI installation path **
RTI_BUILD_TYPE
Win2000-VC6
path
%RTI_HOME%\%RTI_BUILD_TYPE%\bin
RTI_SELECT
RTING
RTI_RID_FILE
%STRIVE_HOME%\AAAAA.rid (AAAAA is your computer
name)
RTI_MULTICAST
224.BBB.CCC.DDD:EEEEE (BBB is the second number
of your IP address)
(CCC is the third number of your IP address)
(DDD is the fourth number of your IP address)
(EEEEE is fourth number of your IP address + 32768)
RTI_CONFIG
%STRIVE_HOME%
Configure Strive
copy %STRIVE_HOME%\STRIVE_v5.rid to %STRIVE_HOME%\AAAAA.rid
Edit %STRIVE_HOME%\AAAAA.rid
Replace 224.142.39.213:32767 by 224.BBB.CCC.DDD:EEEEE
The .fed file is created when the simulation is started if it does not already exist. It is
located in the folder indicated by the STRIVE_HOME environment variable.
CR 2007 - 584
51
D. Configuration du HOTAS Cougar Thrustmaster
To get axes same as ASPB client Help:
52
CR 2007 - 584
If plane goes up and down or turn right and left without touching the flight Stick try to
decrease or increase the center Dead Zone like shown below for the X and Y axis.
Also if you find the joystick to stiff try to reduce the curve.
CR 2007 - 584
53
54
CR 2007 - 584
Set settings as below click save button, do a manual calibration and Click apply.
Don’t forget to save your profile. If done correctly, the configuration made will
always apply even if computer is restarted.
E. Documentation sur la librairie Simulink ASPBLibrairy
ASPB Library
This library contains blocks that interface the CF-18 MCTS API named GsAPI. This
API contains functions that allow configuring the CF-18 MTCS application,
controlling the CF-18 to use it as a viewer or simulating the presence of a real pilot
pressing button. Here some description of each bloc:
*****To use the library make sure it’s in Matlab path*****
CR 2007 - 584
55
Set Flight Control block: This block interface functions that control the position,
orientation, speed of the CF-18. It could be used during simulation as a viewer to
display a plane trajectory.
Set Flight Control on simulation start block: It interface the same function as the Set
Flight Control block but this one take effect only at the beginning of the simulation.
This block could be useful to initiate the plane position, orientation and speed and then
use the autopilot during simulation or to pilot it.
Get Flight Control block: It’s again the same function but now instead of setting value
you retrieve value for the software. It could be useful when needed to retrieve
information on the plane position, orientation and speed while someone is piloting the
CF-18.
Get Flight Control on simulation start block: This block can retrieve the same
information as the Get Flight Control Block but only once at simulation start.
Set Weather block: This block can change the software temperature and wind value
during simulation.
Set Weather on simulation start block: Change temperature and wind value once just
after the user start simulation but before the simulation start.
Get Weather block: Retrieve temperature and wind information during simulation. It
could be used in an autopilot algorithm to tell what to do depending on weather.
Get Atmosphere1 block: This block can acquire the air density, speed of sound and the
static pressure during simulation at a specify location.
Get Atmosphere2 block: This one can get barometric pressure and magnetic variation.
Set Atmosphere1 block: This block can override the magnetic variation when the
override/release input port is 1 but when it is release the MCTS software retrieve
control on this value rewrite any value.
Set Atmosphere2 block: Allow to write the Barometric Pressure wished during
simulation.
Set Atmosphere1 when simulation start and Set Atmosphere2 when simulation start
blocks are the same as the two previous but those allow writing values once and before
simulation start but after the user start the simulation.
Start Scenario block: This one star the scenario in the MCTS software when the user
starts the Simulink simulation. There is an option to start the scenario when ever you
want: user just has to choose the option, click applies and then it starts even if the
simulation in Simulink is not started. Notice that there is a little delay before the
software scenario start. This is probably due to the API itself and not is implantation
in Simulink.
56
CR 2007 - 584
Scenario Time block: With this block it’s possible to modify or retrieve the MCTS
application scenario time while simulation is running
Load Store for a station block: This block allow arming the CF-18 with any missile,
bomb, even fuel tank. User need to choose the station from 1 to 9 but note that some
armament seem to be not loaded correctly maybe because some station can’t host all
kind of weapon.
Load predefined store configuration: This one can load a configuration that already
define what armament goes to each station.
Get status of a store station block: Retrieve the status for a specified station.
Set status of a store station block: Change the status of the specified station but
sometime the change won’t take effect. Probably that is a desired behavior because
the same thing happens when using the MCTS graphic interface.
FLIR switch block: This one allow changing the position of the FLIR switch in the
sensor panel of the MCTS to on, off or standby. It takes effect at simulation start.
LDTR switch block: Change the LTD/R switch to arm or safe.
simulation start. For now, this block doesn’t seem to work.
Take effect at
Start ASPB block: This block only opens a batch file. The batch file contains
command lines that open MC_Emulator and Station Loader Client. This file should be
the same as opening software from shortcuts. Follow instruction on the block!
Unit conversion block: This block help user to transformation nearly any value to
other unit. This block will be useful to provide block input with the correct unit.
Earth transformation functions block: Allow coordinate systems to be transformed
into another. As example, it can transform a geodetic coordinate system into a
geocentric one. It can give some information between two point of a coordinate
system like range, bearing and elevation.
Load Station block: This block was intended to load a station from a Simulink
simulation but some error occurs while using this function. These errors come from
the GsAPI.
Save Scenario block: It was supposed to save the scenario at a specified moment but
for an unknown reason, the compiler doesn’t like the function name.
This library was developed with these tools:
9
9
9
9
9
CR 2007 - 584
Matlab/Simulink Version R2006a
Matlab mex compiler setuped for Microsoft Visual C/C++ version 7.1
ASPB (MCTS) 3.0 Release 4
GsAPI Version 3.0.4 (2007-05-16)
MC_Emulator
57
To compile use this line with the working directory pointing to ASPBmsvc71opts.bat
and filename.cpp:
mex –f ASPBmsvc71opts.bat
ilename.cpp
Other files used by the librairy:
.mexw32 file are needed to run Simulink simulation with ASPB block. These files
were created by compiling the .cpp file. CPP file are not needed for Simulation
running. Also .mexw32 are executable for Windows 32bits.
CF-18Start.bat is the batch file used by the Start ASPB block. It starts MC_emulator
and the Station loader Client.
ASPBTest*.mdl are Simulink scenario used to test each block. Sometimes, simulation
ouputs are compared with values get from the MCTS graphic interface.
ASPBmsvc71opts.bat is used to compile and link CPP file correctly with the GsAPI.
The bat file is based on msvc71opts.bat : a default Matlab compiling setting file use
with Visual studio 7.1. To compile correctly with ASPB’S API, the include and
library directory path of GsAPI and the library GsApiV1.lib was added to
ASPBmsvc71opts.bat.
ASPBEarthScript.m modifies the ASPBEarth block depending on user choices.
F. Information de SESC sur l’installation de VxWorks sur le
MPCU
J’ai configuré le système il y a un peu plus d’un an, il se peut donc que j’oublie
quelques détails…
Si j’ai bien compris, vous avez acheté une carte SVME-183 avec son BSP pour
VxWorks de Curtiss-Wright et VxWorks 5.5 de Wind River. Ma première
recommandation est de lire le document #813343 (Software User’s Manuel,
SVME/DMV-183, Tornado 2.2.1 BSP & Driver Suite) de Curtiss Wright. Il décrit
comment downloader le software dans la carte et plusieurs autres détails.
L’installation du package du BSP sur le PC host, ajoutera entre autre le répertoire
« CWV183 » dans « C :\Tornado2.2\target\config\ » (le root directory peut être
différent). Ce répertoire contient entre autre des exécutables (VxWorks kernel image)
déjà compilés qui peuvent être essayés pour tester le setup, avant de modifier le BSP
(si nécessaire). Normalement lorsque vous recevez le SBC, il devrait déjà contenir le
« boot loader » pour VxWorks 5.5.1 (vous n’aurez donc pas à le modifier).
Pour configurer la carte tu auras besoin d’une connection série entre le COM1 (RS232
CH1 DCE) du SBC et le PC host et d’une connection ethernet entre le « Ethernet 2 »
58
CR 2007 - 584
(sur le connecteur P0 du backplane) du SBC et le PC host. D’autres configurations
sont aussi possibles, mais cette méthode est assez standard et rapide (une fois habitué).
Branchez le câble série entre le SBC et le PC et ouvrir un HyperTerminal (dans
Windows, Start->Programs->Tornado2.2->VxWorks COM1) sur le port série
correspondant du PC. Mettre le power sur le SBC. Si tout fonctionne bien, quelques
lignes de texte seront affichées (General Purpose Monitor) et il y aura un prompt :
(CPU 0) 40000000*
Au prompt entrer : g
Le VxWorks boot s’exécutera et affichera quelques lignes. Attendre ou bien presser
une clé, le prompt apparaîtera : [VxWorks Boot]
Tu peux taper <help> pour avoir la liste des commandes disponibles.
Entrer la commande <c>
Entrer les paramètres suivants :
boot device
: gteth0
processor number : 0
host name
: PC6381 (Le nom du PC host ou n’importe quel nom fera l’affaire)
file name
: C :\Tornado2.2\target\config\cwv183\cpu0_vxWorks (VxWorks
kernel image
inet on ethernet (e) : 132.206.11.11 :ffffff00 (Static IP address du SBC : Subnet
mask)
inet on backplane (b) :
host inet (h)
: 132.206.11.223 (Static IP address du PC host)
gateway inet (g) : 132.206.11.1
user (u)
: sbc183_1 (user name used to access the FTP server on the host PC)
ftp password (pw) (blank = use rsh) : sbc183_1 (password used to access the FTP
server on the host PC)
flags (f)
: 0x8
target name (tn) : sbc183_1
startup script (s) :
other (o)
:
L’adresse IP du PC et du SBC doivent être sur le même subnet et devraient être static
pour ne pas avoir à refaire ces étapes à chaque fois que les adresses changent.
Sur le PC host, partir le FTP server (Start->Programs->Tornado2.2->FTP Server).
Sur le PC host, configurer le FTP server: ajouter un user avec le nom et le password
entré ci-haut (Security->Users/rights… New User).
Redémarrer le SBC, au prompt du HyperTerminal entrer <g>.
CR 2007 - 584
59
Le SBC devrait aller lire l’image du kernel VxWorks sur le PC host en passant par le
FTP server.
Sur le PC, partir Tornado.
Sur le PC, partir le Registry (Start->Programs->Tornado2.2->Tornado Registry), si ce
n’est pas déjà fait.
Dans Tornado, créer un target server (Tools->Target Server->Configure), le configurer
(voici une configuration de base : bouton new, dans le champ Description entrer :
sbc183_1, cocher la boîte « Add description to menu », comme « Target Server
Name » entrer: sbc183_1, dans « Available Back Ends » selectionner « wdbrpc »,
mettre « Timeout » à 10 et « Re-Try » à 3, entrer l’adresse IP du SBC dans « Target
Name/IP Address ») et le partir.
Dans Tornado, dans la drop down list qui est dans la tool bar, sélectionner le target
server qui vient d’être démarré.
Dans Tornado, presser le bouton « Launch Shell » de la tool bar ou bien dans le menu
Tools->Shell… selectionner la target. Ceci partira un Shell dans Tornado, ce shell
peut-être utilisé pour loader et partir l’application que vous développerez.
Au prompt du shell (->) entrer : i
Ceci affichera la liste des tâches qui roulent.
À ce point il faudrait lire le Tornado User’s Guide pour vous partir un projet
(application – downloadable image), le compiler, le downloader avec le Tornado Shell
et l’exécuter.
Peut-être que vous aurez à recompiler un VxWorks kernel pour ajouter certaines
fonctions ou drivers qui ne font pas partie du kernel dans la version
« C :\Tornado2.2\target\config\cwv183\cpu0_vxWorks » fournie par Curtiss Wright.
Pour ce qui est du 1553 qui est sur le SBC (si vous avez acheté cette option), nous
utilisons l’API C/C++ du driver vendu par Curtiss Wright (il ne fait pas partie du BSP
et doit être acheté séparément). Il n’y a aucun assembleur à faire.
G. Différences entre la version classifiée et non classifié de
l’ASPB
La version classifiée permet l’utilisation d’OFP contenant les constantes classifiées
(programme des Mission Computers). La deuxième différence est le modèle radar
plus précis qui intègre des paramètres classifiés de l’APG-73.
Sans les constantes classifiées de l’OFP, les modèles balistiques et les Launch
Acceptability Regions (LAR) dans MC2 sont simplistes et la symbologie associé aux
armes est minimale.
60
CR 2007 - 584
Une partie du modèle de seeker du AIM-9 est désactivée, car il réfère à de
l'information classifiée.
CR 2007 - 584
61
Liste symboles/abrév./acronymes/sigles
62
ACP
Armament Control Processor
ADC
Air Data Computer
AMU
Advanced Memory Unit
API
Application Programming Interface
ARMUX
Armament Multiplex Bus
AVMUX
Avionics Multiplex Bus
CIT
Combined Interrogator & Transponder
CMD
Countermeasure Dispenser
COM
Component Object Model
COM1
Communication Radio #1
COM2
Communication Radio #2
CSC
Communication Set Component
CWS
Countermeasure Warning system
DCOM
Distributed COM
DCS
Digital Communication System
DDI
Digital Display Indicator
DMS
Digital Map Set
DND
Ministère de la Défense Nationale
ECP-583
Engineering Change Proposal
FCCA
Flight Control Computer A
FCCB
Flight Control Computer B
CR 2007 - 584
FLIR
Forward Looking Infrared
GPS
Global Positioning System
HIS
Horizontal Situation Indicator
HLA
High Level Architecture
HLF
High Level Function
HMD
Helmet Mounted Display
HOTAS
hands on throttle-and-stick
HUD
Head Up Display
HWMDGU
Hardware Multi-purpose Display Group Upgrade
HWNNADDI
Hardware Non-Night Attack Digital Display
IBU
Interference Blanker Unit
INS
Inertial Navigation System
ICD
Interface Control Document
LDDI
Left Digital Display Indicator
LMDI
Left Multipurpose Display Indicator
LST
Laser Spot Tracker
MDG
Multipurpose Display Group
Multi-Display Group
MDGU
Multi-purpose Display Group Upgrade
MDI
Multipurpose Display Indicator
MIDS
Multifunctional Information distribution system
MPCU
Multipurpose Computer Unit
MSDR
Maintenance Signal Data Recorder
NNADDI
Non-Night Attack Digital Display
CR 2007 - 584
63
64
OFP
Operational Flight Programs
OS
Operating System
RDDI
Right Digital Display Indicator
RDR
Radar
RMDI
Right Multipurpose Display Indicator
SMP
Stores Management Processor
SMS
Stores Management System
TAC
Tactical
UFC
Up-Front Control Panel
VOR
VHF Omni-Directional Range
WIP
Weapon Insertion Panel
CR 2007 - 584
Liste de distribution
À l’interne
Bibliothèque des documents (3 copies)
Eric Dumais (Autorité scientifique, 1 copie)
À l’externe
Directeur - Gestion du savoir et de l'information (Recherche et développement) (1 CD
avec version PDF)
CR 2007 - 584
65
SANS CLASSIFICATION
COTE DE SÉCURITÉ DE LA FORMULE
(plus haut niveau du titre, du résumé ou des mots-clefs)
FICHE DE CONTRÔLE DU DOCUMENT
1. PROVENANCE (le nom et l’adresse)
2. COTE DE SÉCURITÉ
R & D pour la Défense Canada – Valcartier
(y compris les notices d’avertissement, s’il y a lieu)
2459 boul. Pie-XI Nord
Québec (Québec)
G3J 1X5 CANADA
3. TITRE (Indiquer la cote de sécurité au moyen de l’abréviation (S, C, R ou U) mise entre parenthèses, immédiatement après le titre.)
Mise sur pied d’un banc d’essai pour l’évaluation, le développement, le prototypage, la simulation et la validation de technologies avioniques ( U)
4. AUTEURS (Nom de famille, prénom et initiales. Indiquer les grades militaires, ex.: Bleau, Maj. Louis E.)
David Prevost
DATE DE PUBLICATION DU DOCUMENT 6a. NOMBRE DE PAGES 6b. NOMBRE DE REFERENCES
année)
65
2
Décembre 2007
5.
7. DESCRIPTION DU DOCUMENT (La catégorie du document, par exemple rapport, note technique ou mémorandum. Indiquer les dates
lorsque le rapport couvre une période définie.)
Rapport de contrat
8. PARRAIN (le nom et l’adresse)
3420 rue Lacoste
9a. NUMÉRO DU PROJET OU DE LA SUBVENTIO 9b. NUMÉRO DE CONTRAT
(Spécifier si c’est un projet ou une subvention)
W7701-053273/001/QCL
13ev03
10a. NUMÉRO
EXPÉDITEUR
DU
DOCUMENT
DE
L’OR 10b. AUTRES NUMÉROS DU DOCUMENT
RDDC Valcartier CR 2007 - 584
N/A
11. ACCÈS AU DOCUMENT (Toutes les restrictions concernant une diffusion plus ample du document, autres que celles inhérentes à la cote
de sécurité.)
Diffusion illimitée
Diffusion limitée aux entrepreneurs des pays suivants (spécifier)
Diffusion limitée aux entrepreneurs canadiens (avec une justification)
Diffusion limitée aux organismes gouvernementaux (avec une justification)
Diffusion limitée aux ministères de la Défense
Autres
12. ANNONCE DU DOCUMENT (Toutes les restrictions à l’annonce bibliographique de ce document. Cela correspond, en principe, aux
données d’accès au document (11). Lorsqu’une diffusion supplémentaire (à d’autres organismes que ceux précisés à la case 11) est possible,
on pourra élargir le cercle de diffusion de l’annonce.)
SANS CLASSIFICATION
COTE DE LA SÉCURITÉ DE LA FORMULE
66
CR 2007 - 584
SANS CLASSIFICATION
13. SOMMAIRE (Un résumé clair et concis du document.
Les renseignements peuvent aussi figurer ailleurs dans le document. Il est souhaitable
que le sommaire des documents classifiés soit non classifié. Il faut inscrire au commencement de chaque paragraphe du sommaire la cote de
sécurité applicable aux renseignements qui s’y trouvent, à moins que le document lui-même soit non classifié. Se servir des lettres suivantes:
(S), (C), (R) ou (U). Il n’est pas nécessaire de fournir ici des sommaires dans les deux langues officielles à moins que le document soit
bilingue.)
RDDC Valcartier propose de développer son expertise en développement et tests de systèmes avioniques en étudiant des outils et techniques pour
analyser l'interaction logicielle avec son environnement physique. Ceci inclut : 1) Stimuler les logiciels au niveau de leur interface, 2) Émuler des
systèmes avioniques qui agissent les uns sur les autres par des signaux discrets d'entrée-sortie ou par le bus avionique, 3) Effectuer l'injection de
signal dans les unités de traitement de signaux des senseurs
Ce document présente la première phase de mise sur pied d’un banc d'un essai efficace pour réaliser l'évaluation, le développement et la validation
de technologies avioniques. Le même système sera également réutilisable pour la simulation, le prototypage et éventuellement la certification
logicielle. De plus, l'interaction des logiciels avioniques avec l'environnement physique sera examinée à chaque phase en utilisant le même modèle
d’environnement. Finalement, des dispositions seront prises afin de s'assurer que le banc d’essai pourra également supporter des interactions avec
les systèmes opérationnels lors de tests réels. (U)
14. MOTS-CLÉS,
DESCRIPTEURS OU RENSEIGNEMENTS SPÉCIAUX (Expressions ou mots significatifs du point de vue technique, qui
caractérisent un document et peuvent aider à le cataloguer. Il faut choisir des termes qui n’exigent pas de cote de sécurité. Des
renseignements tels que le modèle de l’équipement, la marque de fabrique, le nom de code du projet militaire, la situation géographique,
peuvent servir de mots-clés. Si possible, on doit choisir des mots-clés d’un thésaurus, par exemple le “Thesaurus of Engineering and Scientific
Terms (TESTS)”. Nommer ce thésaurus. Si l’on ne peut pas trouver de termes non classifiés, il faut indiquer la classification de chaque terme
comme on le fait avec le titre.)
Banc d'essai
Avionique
ASPB
MIL-STD-1553
PC/104
MPCU
VxWorks
SANS CLASSIFICATION
CR 2007 - 584
67
Defence R&D Canada
R & D pour la défense Canada
Canada’s Leader in Defence
and National Security
Science and Technology
Chef de file au Canada en matière
de science et de technologie pour
la défense et la sécurité nationale
WWW.drdc-rddc.gc.ca

Projets Avioniques

Transcription

Documents pareils

cartographie numérique exploitation

Curriculum Vitae en Français. - Justin - Le Site.

Comment trouver votre navette à l`aéroport de Bordeaux

Il est temps de mettre à jour votre Panasonic Toughbook CF-18!

Montchat botté - crèche associative

{46} {4 6 } {4 6 } {4 6 } {4 6 } {46} {46} {46} {4 6 } {4 6 } 5 5 5 5 5

Description de fonction - The British School of Paris

ETABLISSSEMENT D`ACCUEIL JEUNES ENFANTS CHARMETTES