sioc


Cette section est ambitieuse : il s’agit  de se familiariser avec une utilisation complète de  SIOC.

En effet si l’utilisation de FSUIPC, OGS et WideFS/WideClient ne présente pour principale difficulté que leur installation, c’est SIOC qui demande le plus d’étude.

J’ai voulu aborder le problème à partir du « niveau zéro », sans connaissances élaborées en programmation.

Bien sûr il est impossible de rentrer dans tous les détails des connaissances d’un programmeur (que je ne suis pas), et énoncer toutes les notions de base de la programmation serait très fastidieux.

J’ai préféré suivre un fil conducteur « à partir de rien » pour comprendre SIOC et se lancer dans son utilisation en programmation.

Pour les détails plus spécifiques à SIOC, j’ai fait appel à des documents externes que je vous propose, soit disponibles immédiatement en français, soit traduits par mes soins.
Il est en effet inutile de refaire le monde, et en particulier les documents qui existent déjà.




GENERALITES


Structure et traitement des données en informatique.


Fondamentalement, FS est un programme informatique comme les autres.

Un programme informatique a pour fonction de manipuler des données pour atteindre un objectif bien déterminé, selon le rôle du programme.
Cela se fait au moyen d’une série d’instructions qui sont exécutées par l’ordinateur dans un ordre bien établi.
Par exemple « calcule ceci, modifie cela en ça dans telle circonstance, affiche ceci au cas où cela est vrai, fais cela jusqu’à ce que cette valeur soit atteinte, répète cela autant de fois que ceci n’est pas nul, etc… ».

Les données elles-mêmes sont organisées en deux catégories : les constantes, dont la valeur reste identique durant tout le déroulement du programme, et les variables, dont la valeur est modifiée par les calculs du programme.

Ces données concernent tous les aspects du fonctionnement du programme, qu’ils soient perceptibles ou non.
Dans le cas de FS il s’agira par exemple des données d’affichage, que ce soit des menus ou du contenu de l’écran, des options de FS et leur réglage, des sons gérés par FS, des calculs de la position de l’avion, des interactions avec les joysticks ou autres dispositifs etc…

Parmi ces très nombreuses variables se trouvent les données qui concernent directement l’avion et ses systèmes : celles qui nous intéressent pour nos modules de cockpit.

Nous aurons donc besoin de variables comme par exemple la vitesse verticale ou horizontale, le cap, l’altitude etc… et de constantes comme par exemple la puissance d’un réacteur, la longueur ou le poids à vide de l’avion, sa charge maximale etc…

Lorsqu’on le charge, le programme commence toujours par dire à l’ordinateur avec quelles variables il va travailler et éventuellement ce que valent ces variables au début de l’exécution du programme.
L’ordinateur prend alors chacune des variables dans sa mémoire, qui est l’endroit où il va les traiter selon les instructions du programme.

Pour ne pas se perdre dans un fouillis inextricable, ces donnés doivent être organisées : le programme doit savoir précisément de quelle manière et où les retrouver dans sa mémoire.
Il le fait en définissant une série de cases, un peu comme un meuble à tiroirs, dont chacune contient une variable ou une constante.
Comme il y a un nombre gigantesque de tiroirs, chacun porte un numéro et ils sont classés selon ce numéro.

En pratique ces tiroirs sont nommés « adresses » de la mémoire ou encore « offsets ».
Le programme passe donc son temps à ouvrir des tiroirs selon les instructions du type de celles données plus haut, pour examiner la valeur de la variable correspondante et la modifier selon les instructions.

Voici un exemple imaginaire mais réaliste : FS dit à l’ordinateur : « va voir si la variable de position verticale du joystick a changé à l’adresse n° 5674, et si oui modifie dans telle proportion la variable « attitude de l’avion » à l’adresse 3456657,  mais aussi calcule la nouvelle valeur de la variable « vitesse » à l’adresse 345678, modifie la variable « bruit du vent » comme ceci à l’adresse 3894435, modifie la variable « représentation du yoke à l’écran » à l’adresse 26579235234 etc… »




Interactions des programmes entre eux : échanges et modification de variables.

Ce mode de fonctionnement assez simpliste vaut pour tous les programmes.
Donc sont concernés aussi des programmes comme SIOC, OGS, FSUIPC, etc…

Notre but comme constructeurs de cockpit est de faire communiquer des programmes entre eux pour que des actions sur des boutons reliés à l’ordinateur soient relayées à FS de manière à provoquer la modification correspondante sur l’avion, ou à l’inverse que des informations du tableau de bord puissent être représentées sur des éléments matériels reliés à l’ordinateur,  comme des voyants ou des affichages chiffrés.

Il faut agir pour cela à plusieurs niveaux.



Un réseau …

Tout d’abord, il est peu réaliste de charger un seul ordinateur de gérer tout cela à la fois : c’est trop.
Il faudra donc utiliser plusieurs ordinateurs connectés entre eux pour qu’ils puissent échanger les données : un réseau.
En pratique il vaut mieux utiliser un réseau matériel qu’un réseau WIFI (c’est un parti pris), à la fois parce que c’est plus simple (donc plus fiable)  mais aussi plus performant et moins cher.
Les aspects pratiques de la connection de PC(s) en réseau sont exposés dans la section « manipulations ».
Dans un réseau il y aura toujours un PC maître, le « Serveur » et le ou les autres PCs qui viennent se connecter à lui pour faire circuler l’information dans les deux sens : les « Clients » ou « Hôtes ».
Chaque PC est en outre identifié sur le réseau par son « adresse IP », qu’il faut donc absolument avoir défini et retenue pour la mentionner aux logiciels que nous utiliserons.


Des programmes …

Une fois nos PCs connectés et dialoguant entre eux, il faut déployer les programmes nécessaires à notre but primordial : faire le lien entre un bouton et FS (ou OGS).

Actuellement sont utilisés :


Les programmes de base :

1 - Un programme qui connaît les adresses des données de FS qui nous intéressent, et qui peut en outre soit communiquer leur valeur à d’autres programmes, soit modifier des valeurs à la demande d’autres programmes.

Il s’agit de FSUIPC, qui s’installe dans FS même.
Dans le cas de FSUIPC une liste complète des offsets de FS est disponible. On peut donc connaître le numéro des offsets à employer pour les autres programmes qui viendront agir sur FSUIPC.



*** Il existe un autre programme qui peut remplir cette fonction : IOCP de chez opencockpits.
Il ne se limite pas à interagir avec FS : IOCP s’occupe aussi de la communication des programmes de chez opencockpits, ou d’autres programmes  que nous utilisons aussi pour nos réalisations.***



*** Il y a une restriction très importante à ceci : les offsets que connaît FSUIPC sont strictement ceux de FS. Ils ne concernent donc que les fonctions présentes sur les avions par défaut de FS.
Les fonctions supplémentaires plus sophistiquées introduites par des add-ons comme les avions de PMDG ou PIC, etc… ne sont pas renseignées par FSUIPC.
Généralement d’ailleurs les concepteurs de ces add-ons ne veulent pas donner la liste des offsets, protégeant leurs sources… il est donc presque impossible de s’en servir pour nos cockpits, sauf par des voies très indirectes.
C’est très regrettable compte tenu de la qualité intrinsèque de ces add-ons, qui en feraient des modèles parfaits pour nos systèmes.
Il y a à ce jour une seule exception à cet état : les avions de Level-D sont fournis avec les outils nécessaires, mais il s’agit d’un 767…***



2 - Un programme, en deux parties, qui s’occupe de faire circuler l’information depuis FSUIPC vers les autres membres du réseau : WideFS qui s’installe dans FS, et WideClient, qui s’installe sur les autres PCs.
De manière similaire si on choisit IOCP plutôt que FSUIPC, le « serveur » IOCP s’installe dans FS et le « client » IOCP s’installe sur les autres PCs. (voir « réseau » pour les détails de ces appellations). Dans ce cas, IOCP joue à la fois le rôle de FSUIPC et de WideFS.
IOCP comme FSUIPC peuvent aussi répartir l’information entre différents programmes situés sur un même PC.



Les programmes utilisés pour nos besoins spécifiques.

Notre but est de lier OGS à la fois à FS (par FSUIPC ou IOCP) mais aussi au programme qui gère le matériel que nous allons connecter au PC : SIOC.
Ces programmes utilisent donc aussi des variables qui leur sont propres et qu’ils font correspondre à celles de FS grâce à FSUIPC/IOCP.
Elles sont également organisées et stockées dans des adresses qui leur sont propres et que nous devons donc aussi connaître.


3 - OGS sert à intégrer à l’avion de FS les fonctionnalités d’affichage (« glass cockpit ») qui n’existent pas sur les avions de base. Plus tard il intégrera des fonctions supplémentaires comme le FMC etc…
Pour cela il intègre certaines variables de FS et ajoute les siennes.
OGS pour ce faire dialogue avec FS par l’intermédiaire du couple WideClient et FSUIPC.
Il peut aussi utiliser IOCP car il intègre un module « client » IOCP.

OGS a un deuxième but : communiquer avec le programme qui gère le matériel que nous connectons au PC (SIOC).
Cela lui sert à savoir comment ses propres variables doivent changer selon les boutons actionnés, ou envoyer à SIOC les variables OGS à afficher sur les voyants ou afficheurs à chiffres.
Pour communiquer avec SIOC, OGS utilise son module client IOCP.


4 - SIOC : le maillon central de notre chaîne.
Il gère le matériel connecté au PC en définissant pour chaque bouton ou afficheur une variable.
Il se charge aussi de faire correspondre ces variables à celles de FS et OGS.

SIOC joue donc un rôle principal dans la gestion et la circulation des variables.
Il dispose de plusieurs modules pour ce faire.

Un module de communication : il s’agit d’un « serveur » qui utilise IOCP et/ou FSUIPC.

Un module de connection au matériel, c’est à dire aux cartes sur lesquelles sont connectées les boutons et afficheurs.
Quelle que soit leur fonction, les cartes ne peuvent faire circuler l’information que dans deux sens : de la carte vers le PC : « entrées » ou du PC vers la carte : « sorties ».
Les cartes elle-mêmes sont connectées physiquement au PC par un câble parallèle ou USB.

Un module de configuration : il nous permet de définir les variables que nous allons employer dans SIOC, puis de définir les liens entre ces variables propres de SIOC (celles liées aux boutons et afficheurs) et celles des autres programmes (OGS ou FSUIPC).
C’est donc nous qui définirons en utilisant ce module, par exemple que l’action sur le bouton correspondant à l’entrée n°12 de la carte doit correspondre à la valeur « ON » de la variable $64676476 de FSUIPC qui correspond par exemple à l’allumage des feux d’atterrissage.
Ou à l’inverse c’est nous qui dirons à SIOC que la valeur de la variable altitude de FS ou FSUIPC, par exemple $874748567  doit correspondre à l’activation de l’affichage sur un afficheur numérique qui lui se trouve à la variable 539 de SIOC.

Si vous avez compris les explications données jusqu’ici, vous devez pouvoir passer au niveau supérieur en entrant dans le vif du sujet : vous familiariser avec SIOC et ses scripts.




SIOC

Nous avons avec SIOC un programme qui peut recevoir des entrées (inputs) matérielles ou  logicielles, les traiter et éventuellement les modifier selon un scénario bien détaillé, puis les exporter (output) vers une carte ou un logiciel.

A y réfléchir un peu, ce sont là les caractéristiques d’un vrai langage de programmation… et c’est là tout l’intérêt de SIOC par rapport à IOCARDS, l’autre logiciel d’opencockpits : SIOC ne se contente pas de recevoir et envoyer les variables, il permet de les modifier selon des scénarios élaborés, digne d’une intelligence artificielle.

Configurer SIOC c’est donc écrire un programme.
Le programme consiste avant tout en une suite d’instruction qui sont exécutées de manière bien ordonnée.
Dans le cas de SIOC la liste d’instructions se nomme le « script ».
Nous verrons en détail ce qu’il contient.

Programmer ne représente pas une difficulté insurmontable.
Il faut cependant connaître quelques règles fondamentales et le détail du langage de programmation.
Le processus s’apparente beaucoup à une traduction du français vers une autre langue.




Conseils généraux et règles d’or.


Dans tout processus de programmation il y a deux règles d’or absolues.

- la rédaction doit être rigoureuse.
L’ordinateur est une machine puissante mais stupide et dépourvue d’imagination ou de capacité d’adaptation.
Il ne comprend que ce qu’il ne connaît ou reconnaît.
La moindre faute d’orthographe, de syntaxe, de ponctuation ou de mise en page dans une ligne la rendra incompréhensible à ses yeux.

Notre cerveau a la capacité de reconstituer le sense d’un taixte, en corr .
Ri geant les ai, reures
qui ysson présntes pour re trouvver lessens de la fraz.

L’ordinateur n’a pas cette faculté et toute erreur de ce type provoquera le blocage du script.



- il ne faut rien laisser au hasard mais être structuré et organisé.
Ce n’est pas en écrivant un programme que l’on réfléchit à ce qu’on va écrire.
Cette réflexion doit être menée avant la rédaction, et de manière complète.

Pour comprendre cette notion, reprenons la comparaison : avant de commencer à traduire un texte dans une autre langue, il faut un texte à traduire.
Ce texte doit être complet et tous ses aspects doivent être fixés avant le travail de traduction à proprement parler, soit la rédaction du programme.

Avant de commencer il faut donc avoir rédigé un « scénario » complet et précis en langage courant.
Il est très important également que toutes les variables à utiliser soient répertoriées et nommées : cela évite de s’embrouiller en cours de rédaction.
Aussi bien celles de FSUIPC ou des autres programmes externes, que celles que nous allons définir dans SIOC même.
La liste doit donc être impérativement dressée avant toute rédaction.




Comment apprendre à rédiger en SIOC ?

En pratique, on s’y prend comme pour apprendre et utiliser une nouvelle langue.

On commence par acquérir un vocabulaire, qui dans le cas de la programmation n’est jamais très étendu.
Comme dans une langue, le vocabulaire comprend différents types de mots ayant chacun un rôle différent.

Sans rentrer dans les détails, il s’agit des variables, des attributs, des liens, des opérateurs, des commandes et des fonctions.


Ensuite on apprend la syntaxe : comment rédiger, comment mettre en page, comment mettre la ponctuation.

Il est tout à fait recommandé de se familiariser avec la rédaction d’un script SIOC en lisant et analysant des scripts déjà rédigés, pour savoir comment s’y prendre ou utiliser les instructions, comment elles agissent etc...

On peut alors s’exercer à composer des petits textes pour mettre en pratique ses acquis.
En s’aidant d’exemples d’autres textes (scripts)  pour apprendre à rédiger.

Par exemple un petit script de quelques lignes modifiant quelques variables, qu’on peut tester pour savoir si on est dans le bon …

Enfin on se lance à rédiger un texte définitif dans toute sa complexité.




Comment programmer en SIOC ?

Le script est donc l’ensemble des instructions permettant à SIOC de relier les dispositifs matériels (boutons, encodeurs, afficheurs, axes de joysticks etc…) aux fonctions de FS, mais aussi de les faire correspondre aux variables des autres programmes (OGS, etc…) et également de les modifier selon un scénario bien ordonné.

Nous pouvons reprendre un script existant et éventuellement le modifier pour qu’il corresponde à notre construction : c’est la méthode la plus simple.

Nous pouvons aussi le rédiger à partir de zéro pour arriver à gérer tout le matériel que nous allons utiliser.
SIOC facilite la rédaction d’un script en l’automatisant en partie mais il est aussi possible de le rédiger sans aucun automatisme : « à la dure ».
Je vous conseille de n’utiliser ce dernier mode de rédaction « à la dure » que lorsque vous serez bien rodé à la rédaction automatisée de SIOC.

Dans tous les cas il s’agira de traduire du français vers le langage SIOC.

Par exemple il faudra traduire le fait que si le bouton de la carte comandant les feux d’atterrissage est enclenché, les feux d’atterrissage doivent s’allumer dans FS.

La première étape revient à conceptualiser que l’enclenchement du bouton modifie une variable dans les entrées de SIOC, et qu’il faut relier l’état « activé » de cette variable à celle de FSUIPC qui correspond aux feux d’atterrissage de FS.

La seconde reviendra à composer les instructions correspondantes dans la « langue SIOC » avec les instructions et les noms de variables adéquats.


Cependant un script SIOC a une structure bien déterminée et comprend plus que la simple liste des instructions.

La première partie du programme sert à dire à l’ordinateur quelles variables vont être utilisées.
Cette « déclaration » des variables est indispensable, l’ordinateur ne reconnaîtra dans le programme que les variables qui lui ont été déclarées.
D’où l’intérêt de les avoir répertoriées, organisées et nommées dans le projet rédigé sur papier avant toute programmation.

Vient ensuite le code proprement dit : la série d’instructions pour l’entrée, la manipulation et la sortie éventuelle des variables. En le rédigeant, on s’attache donc à respecter strictement la syntaxe, l’orthographe et la ponctuation.

On peut séparer chaque section du programme (par exemple la partie qui gère les interrupteurs des feux, la partie qui gère les boutons de l’EFIS, etc…).
Les langages de programmation comme SIOC permettent de délimiter ces différentes parties par des lignes commençant par des caractères spéciaux, qui ne sont pas interprétées par l’ordinateur comme des lignes de programmes : il les passe lorsqu’il les rencontres et elles ne servent qu’au rédacteur du code.
Elles permettent de mettre des titres ou des commentaires aux sections rédigées.

Une fois le code terminé, il faut enregistrer le scrip au format spécial .ssi : ce format est une traduction en langage plus direct pour SIOC et l'ordinateur, mais incompréhensible à la lecture.
Ce processus s'appelle la compilation.
(vous pouvez l'enregistrer en format .txt mais dans ce cas avant de l'employer il faudra le compiler).
La compilation est l'épreuve de vérité de votre travail : c'est là que les erreurs d'orthographe, de ponctutation ou de syntaxe, mais aussi les variables non déclarées seront identifiées et généreront un blocage ou une erreur.

Commencer la programmation en SIOC.

Avec ces conseils et principes de base, nous sommes prêts à rentrer dans le vif du sujet et apprendre SIOC.

C’est ici que je fais appel à des ressources extérieures.


- Pour commencer, et découvrir SIOC en douceur, petit à petit, jusqu’à découvrir des exemples de programmation, je vous conseille de lire l’excellent tutoriel de C. Keiffer : SIOC pas à pas.
La logique de fonctionnement y est très bien décrite et vous y trouverez des exemples d’utilisation des fonctions de SIOC.


- Ensuite il est temps d’approfondir en étudiant une présentation complète de SIOC.
Vous pouvez télécharger un tutoriel rédigé par les concepteurs de SIOC eux-mêmes et adapté par votre serviteur.

- SI vous voulez entrer dans le vif du sujet par une autre porte, le "site des deux Pierre" présente entre autres pages, une section très didactique dédiée à SIOC : on y trouve un excellent tutoriel sur l'apprentissage de SIOC. Pour rentrer en douceur dans le vif du sujet et devenir un pro sans souffrir. Le site est aussi dédié au Baron, mais ce qui vaut pour le Baron vaut aussi pour les Boeing "roturiers"... :)

- L’étape suivante consiste à disposer d’une description systématique des fonctions de SIOC :
un guide de référence complet de ses commandes et de son utilisation pratique. Peut-être ardu à lire d'une seule traite, mais la bible pour la programmation en SIOC.
Ce guide est disponible également sur opencockpits, traduit par votre serviteur…
Il s’agit de la traduction de l’aide en ligne de SIOC, d’où le nom du document …


- Vous pouvez également télécharger et lire le manuel en français de SIOC rédigé par M. Velez d’opencockpits.
Il s'agit cpendant du manuel de la version 1.0 de SIOC : pas très à jour donc mais déjà une bonne base de travail.


- Pour disposer d’une autre source d’exemples pratiques d’utilisation de SIOC,
Vous pouvez vous référer également aux travaux de Nico Kaan, à voir sur son site.

Il a en effet développé pour le Boeing 767 de Level-D une application permettant d’interagir avec les variables de ce magnifique add-on.
Bien plus que cela, il a conçu un script SIOC permettant de relier l’intégralité des éléments d’un cockpit matériel à toutes les fonctions du 767 de Level-D (y compris le FMC, l’overhead etc…).

Même si ce travail est spécifique au 767, il a également rédigé un tutoriel sur SIOC avec différents exemples de gestion avancée des fonctions du cockpit.
Une excellente source d’inspiration pour nos travaux de rédaction destinés à un cockpit de 737…
Avec son accord j’ai réalisé une traduction de ce tutoriel, vous pouvez vous en inspirer comme exemple.

Cerise sur le gâteau, il a mis à disposition depuis peu sur son site un script SIOC permettant de faire interagir le Boeing 767 de Level-D avec … le MCP vendu assemblé de chez opencockpits !


- La dernière ressource que je vous propose est le forum d’opencockpits.
La section consacrée à SIOC vous permettra d’y poser toutes vos questions et de découvrir des exemples de scripts à utiliser.