INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Pour réaliser des matrices combinées de flexibilité et redondance, on part de modules ou structures élémentaires formés de blocs d'entrée/sortie du type de ceux représentés sur les figures 3a à 3e et de blocs d'interconnexion repré sentés sur les figures 4a à 4d.
Les blocs d'entrée/sortie (figure 3a à figure 3e) servent à réaliser des réseaux d'entrée/sortie qui seront décrits plus loin en relation avec les figures 5 à 8 et, à partir de réseaux d'entréelsortie et de blocs d'interconnexion, on forme les matrices combinées de flexibilité et de redondance qui seront decrites plus loin à partir de la figure 9.
Le premier type de bloc d'entrée/sortie représenté la figure 3a est dénoté Sl. II comporte un commutateur 30, une entrée 32 de matrice, une sortie 34 de matrice et deux connexions 36 et 38. Par connexion, en entend ici une borne destinée à être reliée à une borne d'un bloc d'interconnexion. La position du com mutateur 30 représentée sur la figure 3a connecte l'entrée 32 à sortie 34. Mais, bien entendu, comme décrit en relation avec les figures 2a à 2d, rotation du com mutateur 30 permet de relier la connexion 36 à l'entrée 32 et la connexion 38 à la sortie 34. On peut également relier entre elles les connexions 36 38. Dans la der nière position, l'entrée 32 est reliée à la connexion 38 et la connexion 36 est reliée à la sortie 34. Pour les autres commutateurs représentés sur les autres figures, il n'est pas utile décrire en détails les diverses positions puisqu'elles résultent de la structure commutateur.
bloc d'entrée/sortie S2 représenté sur la figure 3b comporte deux com mutateurs et 42. Au commutateur 40 sont connectées une entrée 44 et une sor tie 46 et, commutateur 42, sont connectées une entrée 48 de matrice et une sor tie 50 de matrice. La borne X2 du commutateur 40 est connectée la borne X4 du commutateur 42 par une liaison 52. La borne X4 du commutateur 40 est reliée à une connexion 54 et, de même, la borne X2 du commutateur 42 est reliée à une connexion 56. Le bloc d'entréelsortie S3 représenté sur la figure 3c comporte un - mutateur 60, une entrée 62 de matrice et deux connexions 64 et 66 connectées aux bornes X2 et X4 du commutateur 60. La borne X3 du bloc S3 est en l'air.
Le bloc d'entrée/sortie S4 représenté sur la figure 3d comprend deux com mutateurs 70 et 72. La borne X1 du commutateur 70 est reliée à une entrée 74 de matrice et, de meure, la borne X1 du commutateur 72 est reliée à une entrée 76 de matrice. La borne X3 du commutateur 72 est reliée à une sortie 78 de matrice. La borne X2 du commutateur 70 est reliée à la borne X4 du commutateur 72 par une liaison 80. La borne X3 du commutateur 70 est en l'air. La borne X4 de ce dernier commutateur liée à une connexion 82. Enfin, une connexion 84 aboutit à la borne X2 du commutateur 72.
Le bloc S5 représenté sur la figure 3e comprend seulement une entrée 90 de matrice et une connexion 92.
Un bloc, ou matrice, d'interconnexion (figures 4a à 4d) comprend un nombre pair 2r de bornes et il assure la liaison d'une sélection quelconque de r bornes vers les r bornes restantes.
Dans l'exemple le plus simple de la figure 4a, on prévoit seulement deux bornes et le bloc 100 est constitué par un simple fil.
Dans l'exemple de la figure 4b, le bloc 102 comporte un simple commu tateur (quatre bornes).
Dans le mode de réalisation représenté sur la figure 4c, le bloc 104 com prend trois commutateurs 106, 108 et 110 dont les bornes X2 sont reliées à des connexions, respectivement 1061, 1081 et 1101 et dont les bornes X4 sont reliées à des connexions, respectivement 1062, 1082 et 1102. La borne X3 du commutateur 106 est reliée à la borne X1 du commutateur 108. De même, la borne X3 du com mutateur 108 est reliée à la borne X1 du commutateur 110 et, enfin, la borne X1 du commutateur 106 est connectée à la borne X3 du commutateur 110.
Le bloc d'interconnexion 114 représenté sur la figure 4d comprend six com mutateurs respectivement 116, 118, 120, 122, 124 et 126. Ce bloc d'interconnexion 114 comporte deux fois quatre bornes ou connexions, à savoir des connexions 130 et 132 reliées à des bornes du commutateur 116, des connexions 134 et 136 reliées à des bornes du commutateur 118, des connexions 138 et 140 reliées à des bornes du commutateur 124 et des bornes 142 et 144 reliées à des bornes du commutateur 126.
Des liaisons sont prévues entre les autres bornes des commutateurs : une liaison 150 entre une borne du commutateur 116 et une borne du commutateur 122, une liaison 152 entre une borne du commutateur 118 et une borne du commutateur 120, une liaison 154 entre une borne du commutateur 116 et une borne du com mutateur 120 et une liaison 156 entre une borne du commutateur 118 et une borne du commutateur 122. Des liaisons analogues sont prévues du commutateur 120 vers les commutateurs 124 et 126 et, de même, du commutateur 122 vers les com mutateurs 124 et 126.
Les blocs d'entrée/sortie à S5 représentés sur les figures 3a à 3e peu vent être associés pour constituer des réseaux d'entrée/sortie. L'association est effectuée en parallèle de façon telle que chaque réseau comporte un nombre de bornes de connexion égal au nombre pair 2r de connexions d'un bloc d'inter connexion 100, 102, 104, 114 (figure 4a à figure 4b). Autrement dit, un réseau d'entrée/sortie devra comporter six bornes de connexion s'il est associé à des blocs d'interconnexion à six bornes de connexion, comme celui représenté sur la figure 4c.
Pour générer un composant, il est nécessaire de définir les fonctionnalités externes au composant et dont il aura besoin d'utiliser les résultats lors de son exécution ; ceci relève d'une démarche d'analyse fonctionnelle classique.
Par contre, comme on va le comprendre, le système selon l'invention conserve les informations sémantiques issues de cette phase d'analyse fonctionnelle jusque dans le cadre de l'exécution du composant.
Ceci facilite grandement les évolutions du système et augmente sa lisibilité.
Les fonctionnalités externes au composant sont décrites dans le fichier source d'interface du composant, à l'aide du langage de dépendances créé par la Demanderesse et évoqué plus haut.
Plus précisément, chaque fichier source INT d'interface associé à un composant C permet de décrire totalement ce composant. II décrit, les éléments d'interface qu'il doit importer d'autres composants, et ceux qu'il exporte vers d'autres composants.
Ce fichier sera compilé (à l'aide d'un fichier de compilation MF, appelé encore Makefile) et lié au(x) fichier(s) objet correspondant au code de la partie implémentation IMP (c'est à dire à chacun du ou des fichier(s) source(s) de la partie implémentation du composant), pour former le module M composant qui constitue la version exécutable du composant, comme représenté schématiquement sur la figure 5 ci-après. Le langage de dépendance utilisé pour créer les fichiers sources d'interface sera expliqué plus loin dans ce texte.
Un module M peut alors être chargé sur une cible 50 cible étant définie comme le matériel informatique sur lequel le système logiciel selon l'invention fonctionne), et être immédiatement reconnu les autres composants présents sur cette cible, comme cela va être détaillé.
# La partie implémentation du composant La partie implémentation IMP est le coeur opérationnel du composant. C'est la partie qui permet la réalisation effective de la fonctionnalité du composant. Cette fonctionnalité peut être réalisée de différentes façons par la partie implémentation, suivant les fonctions mises en oeuvre le code.
Ainsi, différents composants peuvent chacun réaliser une même fonctionnalité, mais en prenant en compte des critères différents, critères qui peuvent etre prédéterminés lors de la conception de l'application ou du programme qui fait intervenir le composant, ou déterminés dynamiquement lors de l'exécution même de l'application.
Ces critères sont décrits sous forme de propriétés (par exemple void, char, etc.... associées à l'interface du composant, qui seront décrites plus loin dans texte.
Les critères sont exprimés en fonction d'une de ces propriétés, qui est définie dans l'interface du composant qui exporte la fonctionnalité, l'interface composant qui importe la fonctionnalité associant un opérateur comparaison à cette propriété ( , =, etc... comme décrit ci- dessous), ainsi qu'une valeur de comparaison.
Et il est possible d'adapter le système ou l'application de façon statique ou dynamique, en fonction de critères externes au composant (matériels par exemple), ou de l'état actuel du système et de l'application lors l'exécution.
Le fichier d'interface de chaque composant fournit ainsi un ensemble de meta-informations , qui permettront comme on va le voir à un composant spécifique du système (le gestionnaire de dépendances) gérer de manière pertinente les relations entre les composants, en fonction des critères évoqués plus haut (qui peuvent concerner une version du composant, une localisation de ce composant, une donnée l'état du système... ).
Et on précise que si chaque fonctionnalité peut etre réalisée uniquement par un code (implémentation logicielle de la fonctionnalité), il également possible de faire intervenir au moins un élément de hardware pour remplir la fonctionnalité (implémentation materielle de la fonctionnalité).
# La partie interface du composant La partie interface permet de décrire précisément quelle fonctionnalité est fournie par le composant et quelles fonctionnalités devront lui être fournies, lors de son exécution.
Elle définit, dans le langage de dépendances développé par la Demanderesse, le format des données devant être fournies en entrée au composant et le format des données en sortie du composant. Ce format est dépendant uniquement de la fonctionnalité réalisée, et non de la façon dont la fonctionnalité est réalisée par la partie implémentation.
Pour ce message maj~cpt modifiera le compteur stock et le compteur attente et verra s'il faut ou pas lancer un ordre de fabrication ou d'achat. oMessages de sortie oPasser ordre de fabrication ou d'achat #(POF, 07-12-1998,référence, -, lot,-, nom~fonction, N) pour les articles internes.
Ce message est créé par maj~cpt suite à un test au niveau du compteur attente, du lot et du P/C (compteur~att > Lot/PC), pour les articles gérés en kanban et au test du compteur stock plus en cours par rapport au seuil de commande ((compteur~stock + compteur fabrication) > seuil de commande), si le mode de gestion est celui du seuil de commande.
Ce message sera récupéré par la GPAO et au retour nous recevrons le message OF. nom~fonction : va correspondre au nom de la procédure qui lance le message. o(POA, 07-12-1998, référence,-, lot, nom~fonction, N) pour les articles externes.
Même traitement que celui pour POF.
Clôture Lot de fabrication (CFL, 07-19-1998, référence, qté~lancé, qté~clôturé, numéro~lot,-, CL, N) Ce message est récupéré par la GPAO et envoie comme réponse une réception de fabrication.
Edition des étiquettes #(EDIT~ETI, 07-12-1998 ,référence , - ,qté~éti~éditer,num~lot,-,KBI,N)
Ce message va être récupéré par le programme d'impression des étiquettes (edit~eti), qui éditera toutes les étiquettes appartenant au numéro du lot passé dans le message.
(EDIT~ETI, 07-12-98,référence, l, numéro~étiquette, -, REIMP, N) ce message est également récupéré par (edit~eti) et fait l'édition d'une étiquette.
La fiche Article contient les éléments nécessaires et suffisants à l'utilisation du procédé : #Le Type : Externe ou interne déclenche des Achats ou des Ordres de Fabrication.
#Le Mode Gestion : Kanban ou Seuil de Commande. oLe Lot : Donnée de lancement d'Ordre de Fabrication ou de purge de commande #Le nombre d'Articles par contenant calcule le nombre d'étiquettes.
[]Les éléments nécessaires au calcul de la Consommation Moyenne Journalière.
Une interface de saisie permet de saisir des nomenclatures simplifiées qui identifient uniquement et simplement des composants suivis en KANBAN et qui alignent automatiquement le Besoin Brut issu des produits-fini à un Besoin Brut matières associés.
Les Articles doivent exister dans le fichier Article.
Remarque : Les articles saisis dans le PDP sont identifiés par le programme de saisie. Les articles générés automatiquement dans le PDP par le calcul des Besoins Bruts sont également repérés.
Avant de recalculer les besoins bruts, on pourra éliminer les enregistrements générés automatiquement afin de réactualiser les besoins.
Le Plan Directeur de Production est, s'il n'existe pas déjà dans votre GPAO, le point de départ du
L'instruction "simple" permet quant à elle de déclarer une variable de type simple, c'est-à-dire une variable pouvant contenir une chaîne de caractères, un entier ou un flottant. Elle se caractérise par le nom de la variable et par la valeur que prend éventuellement cette variable à l'initialisation.
L'instruction "créer" permet de construire un objet ou une liste d'objets SIDL déclarés dans le contexte courant ou dans le service courant. Elle se caractérise par le nom de la variable à construire, le constructeur SIDL à utiliser, et les valeurs affectées aux paramètres du constructeur.
On présente, en annexe 3, quelques exemples d'instructions de type "manipulation de variables".
Selon une troisième caractéristique avantageuse de l'invention, lesdites instructions de type "navigation" appartiennent au groupe comprenant : - une instruction "changer - contexte", permettant d'instancier un nouveau contexte ; - une instruction "changer - service", permettant d'instancier un nouveau service ; - une instruction " contexte - précédent", permettant de revenir au contexte précédent dans le service courant ; - une instruction "service - précédent", permettant de revenir au contexte précédent avec le dernier contexte dudit service.
En effet, à un instant donné, pour un client donné (c'est-à-dire pour un terminal donné ayant émis une requête à destination du système de publication multi - terminal selon l'invention), il existe un unique contexte courant et un unique service courant. Le langage MDSP permet de changer ce contexte courant et ce service courant par l'entremise d'instructions de type "navigation".
Ainsi, une instruction "contexte-précédent" permet de revenir à un contexte précédent dans le service courant. Le contexte courant devient alors ce contexte, dans l'état où on l'a quitté la dernière fois. La présentation retournée au terminal ayant émis la requête correspond donc à celle décrite par le dernier composant de type "contenu" exécuté sur ce contexte.
On présente, en annexe 4, quelques exemples d'instructions de type "navigation".
Selon une quatrième caractéristique avantageuse de l'invention, lesdites instructions de type "utilisation" appartiennent au groupe comprenant : une instruction "appel", permettant d'appeler un composant "méthode" dans le contexte ou le service courant ; une instruction "si", permettant d'établir une condition sur un ensemble d'instructions ;
une instruction "sinon", faisant suite à une instruction "si" et permettant d'établir une condition sur un ensemble d'instructions ; une instruction "sinon - si", faisant suite à une instruction "si" et permettant d'établir au moins une autre condition sur ledit ensemble d'instructions ; une instruction "exécuter - contenu", permettant de générer une présentation desdites informations décrites dans un composant "contenu" ; une instruction "SIDL - import", permettant de spécifier un objet à utiliser dans le service courant ; une instruction "paramètre - liste", permettant de regrouper des déclarations de paramètres ; une instruction "paramètre", permettant de spécifier la valeur d'un paramètre ; une instruction "faire", permettant de regrouper dans un composant du type "traitement" des actions à effectuer au lancement de l'exécution d'un contexte ; une instruction "sur", permettant de regrouper des conditions devant être validées pour qu'un composant du type "traitement" s'exécute.
En effet, il existe également, au sein du langage MDSP, des instructions diverses qui peuvent être utilisées par des instructions ou des composants.
Ainsi, une instruction "appel" permet d'appeler une méthode (c'est - à - dire un composant du type "méthode") déclarée dans le contexte courant ou dans le service courant. Elle se caractérise par le nom de la méthode appelée et par les valeurs affectées aux paramètres de la méthode.
Une instruction "exécuter - contenu" permet de déclencher la génération de la présentation des informations décrites par un composant contenu. Elle se caractérise par le nom du contenu dont on veut générer la présentation et le nom du modèle XSL que l'on veut utiliser, si l'on ne veut pas utiliser celui du contenu.
On présente, en annexe 5, quelques exemples d'instructions de type "utilisation".
Avantageusement, à la réception par ledit au moins un module de création d'objets d'une demande d'au moins un objet, ladite demande venant dudit module de génération de réponse, ladite au moins une fonction de création d'objets met en #uvre au moins une sous-fonction d'extraction, permettant de renseigner le contenu d'au moins un membre relatif à la structure dudit au moins un objet.
De façon avantageuse, ladite au moins une fonction de création d'objets comprend en outre une sous-fonction de comparaison dudit au moins un objet sur lequel porte ladite demande avec une liste d'objets préalablement au moins partiellement créés, de façon à ne mettre en #uvre ladite au moins une sousfonction d'extraction que pour la création d'objets non préalablement créés et/ou pour compléter des objets préalablement partiellement créés.
Ainsi, si un objet a déjà été créé en réponse à une requête, traitée précédemment par le système de publication multi - terminal selon l'invention, cet objet est réutilisé dans l'élaboration de la réponse à la requête en cours de traitement, et est directement envoyé au module de génération de réponse.
des exemples de disposition de diodes photoémissives consti-
tuant chaque source lumineuse de la lampe de véhicule; et les figures 9(a) à 9(e) sont des schémas représentant
tuant chaque source lumineuse de la lampe de véhicule.
La figure 1 est une vue en élévation d'une lampe 10 de
véhicule selon l'invention, la figure 2 une coupe hori-
zontale de cette lampe, et la figure 3 une coupe détaillée
suivant la ligne III-III de la figure 1.
Comme l'indiquent les figures i à 3, la lampe 10 de véhicule selon l'invention est une lampe arrière combinée
placée à la partie d'extrémité arrière gauche d'un véhicule.
Cette lampe 10 comporte deux unités 12A et 12B à lampe logées dans une chambre de lampe. Cette chambre comporte un corps 14 de lampe ayant un contour allongé latéralement, une
glace translucide continue 16, et un panneau 18 de protec-
tion qui entoure ces unités 12A et 12B à lampe.
La lampe 10 de véhicule est utilisée fonctionnellement comme lanterne, comme feu de stop et comme clignotant. Plus précisément, l'unité 12A placée du côté interne du véhicule dans la direction de la largeur peut fonctionner en mode d'éclairage de lanterne et en mode d'éclairage de feu de stop. L'unité à lampe 12B placée du côté extérieur du véhicule dans la direction de la largeur peut être mise en fonctionnement en mode d'éclairage de lanterne et en mode
d'éclairage de clignotant.
On décrit d'abord la construction de l'unité à lampe
Cette partie interface permet de constituer une description de la fonctionnalité réalisée par le composant, indépendamment de la manière dont cette fonctionnalité est réalisée par la partie implémentation. En effet, quel que soit le mode de mise en oeuvre de la fonctionnalité par un code (ou par un élément matériel programmé), cette fonctionnalité reste identique. Elle effectue les mêmes traitements, demande les mêmes informations en entrée et fournit les mêmes données en sortie. La partie interface autorise donc largement les évolutions du système. Une implémentation logicielle d'une fonctionnalité (correspondant à un composant dont la partie implémentation est constituée de code) pourra ainsi être réalisée plus tard par une implémentation matérielle .
Dans ce cas, le composant correspondant comprend un fichier d'interface, mais sa partie implémentation est constituée d'un programme très simple décrivant la liaison avec l'élément matériel.
Inversement, une implémentation matérielle pourra être remplacée sans aucun impact sur les autres composants par une implémentation logicielle d'une fonctionnalité.
Une interface est définie avec le mot-clé interface dans la description du module du composant.
Le tableau suivant décrit différentes propriétés d'une fonctionnalité ; ces propriétés peuvent concerner des fonctionnalités demandées par le composant (sens = import), ou la fonctionnalité que le composant fournit (sens export)
Propriété Sens Description unique Export Une seule implémentation de cette interface peut exister sur un système local. Le système ne chargera donc que la première implémentation et rejettera les suivantes. foreign Import L'interface est importée d'un autre composant loadtime import L'interface est chargée automatiquement, en même temps que le composant qui l'utilise. runtime Import L'interface sera chargée sur demande du composant qui l'utilise (gestion dynamique - voir les paragraphes sur le estionnaire de dépendances). required Import L'interface est indispensable pour le fonctionnement. Le composant ne sera pas chargé si la fonctionnalité associée à cette interface n'est pas effectivement importée.. multiple import Importe tous les composants qui exportent la fonctionnalité demandée par cette interface. C inprocess supervisor module interface component { /* Définition de l'interface exportée */
foreign loadtime required interface codec /* Définition de l'interface import */ Propriétés d'une interface Les propriétés d'une interface permettent de définir critères évoqués plus haut dans ce texte. Elles sont typées, comme en langage C (marque déposée). Le tableau suivant décrit les différents types de propriétés
Propriété Descripfion, , void Void (équivalent au type C) char Entier 8 bits short Entier 16 bits int,long Entier 32 bits long long Entier 64 bits float Flottant double Double (équivalent au type C) struct narre Structure union narre Structure string Chaîne UTF-8 terminée par un zéro Boolean Booléen memarea Zone mémoire enum narre Enumération (enum) Les extensions suivantes peuvent être associées à ces propriétés
Extension Description signed Valeur signée (par défault) unsigned Valeur non signée const 'Valeur constante => Opérateurs sur les propriétés des fonctionnalités Lors de la description des dépendances dans le fichier d'interface, des opérateurs permettent de préciser les propriétés interfaces. Ils permettent ainsi de n'autoriser l'importation d'une autre interface que si la valeur d'une propriété de cette autre interface correspond un critère bien défini.
Les opérateurs suivants peuvent être associés aux propriétés des interfaces
Opérateur " Dëscription """" in Ce paramètre est une entrée (par défault) out @ Ce paramètre est une sortie et sera renseigné par la fonctionnalité appelée, inout Ce paramètre est une entrée/sortie. = Opérateur d'assignement _= Idem langage C Idem langage C Idem langage C > Idem langage C ≥ Idem langage C != Idem langage C ET booléen Le résultat du ET logique est différent de zéro Inverse de ( & & ) Le résultat du ET logique est zéro Le mot-clé undef peut être utilisé comme valeur comparaison pour les propriété ou les fonctions. Dans l'exemple dessous, le composant considéré nécessite une interface nommée codec, contenant une propriété entier 32 bits nommée mainType, dont la valeur doit être 2 exactement. Cette interface doit faire réaliser une fonctionnalité Func()prenant en paramètre une chaîne de caractères et retournant un entier signé 32 bits.