INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Elle concerne aussi un ensemble de deux matrices de flexibilité et de redondance, dont l'une comporte n+f entrées et n+p sorties et dont l'autre comporte n+p entrées et n+f sorties.
D'autres caractéristiques et avantages de l'invention apparaîtront avec la description de certains de ses modes de réalisation, celle-ci étant effectuée en se référant aux dessins ci-annexés, sur lesquels la figure 1 déjà décrite montre un ensemble de canaux d'émissionlréception avec des matrices de flexibilité et de redondance, ainsi que des amplificateurs, cor respondant à l'état antérieur de la technique, les figures 2a, 2b, 2c et 2d sont des schémas montrant un commutateur et son mode de fonctionnement, figures 3a à 3e représentent des blocs d'entrée/sortie constituant des modules elémentaires conformes à l'invention pour la réalisation de matrices com binées de flexibilité et de redondance, les figures 4a à 4d sont des schémas montrant des modes de realisation de blocs d'interconnexion conformes à l'invention, la figure 5 est un schéma de réseau d'entrée/sortie formé à partir de blocs d'entrée/sortie du type représenté sur la figure 3b, les figures 6a à 6c sont des schémas de réseaux d'entrée/sortie constitués d'un ensemble de blocs d'entrée/sortie du type de ceux représentés sur la figure 3a ou sur les figures 3a et 3b, les figures 7a à 7f sont des schémas de réseaux d'entrée/sortie formés à partir d'au moins un type de bloc d'entréelsortie représenté sur les figures à 3d, les figures 8a à 8k sont des schémas montrant des exemples de réseaux d'entrée/sortie formés à partir d'au moins un type de bloc d'entrée/sortie représenté sur les figures 3a à 3e, la figure 9 est un schéma montrant la structure d'ensemble d'une matrice conforme à l'invention, la figure 10 est un exemple de mode de réalisation de matrice du type de celle représentée sur la figure 9 et comportant des blocs d'interconnexion du type de celui représenté sur la figure 4c, ainsi que des réseaux d'entrée/sortie du type de ceux représentés sur l'une ou l'autre des figures 5, 6a à 6c, 7a à 7f et 8a à 8k, les figures 11 à 11q et 121 à 1242 montrent plusieurs modes de réalisation de matrices conformes à l'invention.
Une matrice combinée de flexibilité et de redondance conforme à l'inven tion comporte, de façon classique, une pluralité de commutateurs du type de ceux représentés sur les figures 2a à 2d.
Chacun de ces commutateurs comporte quatre bornes fixes X1, X2, X3 et X4 et une pièce tournante rc présentant des chemins conducteurs C1, C2 et C3. Dans la position représentée sur la figure 2a, le chemin conducteur C2 relie la borne X1 à la borne X3.
Dans la position représentée sur la figure 2b, la pièce tournante a effec tué, par rapport à la position de la figure 2a, une rotation d'un huitième de tour dans le sens contraire aiguilles d'une montre et, dans ce cas, le chemin conducteur C1 relie la borne à la borne X4 et le chemin conducteur C3 relie la borne X2 à la borne X3.
Après nouvelle rotation d'un huitième de tour (figure 2c), la borne X2 est reliée à la borne X4 par le chemin conducteur C2.
De même, la structure de modèle d'un contrat, appelé aussi modèle SLA est décrite sous forme générique au moyen d'une grammaire de modèle SLA. La structure de modèle de contrat permet de définir lors de l'étape S5 au moins un modèle de contrat 90, aussi appelé modèle SLA.
Chaque critère SLA qui compose un contrat et qui est défini dans la structure sous la forme générique, c'est-à-dire indépendante de la technologie, est appelé dans le modèle SLA 90 un prototype 91 de critère SLA. Dans un modèle SLA 90, chaque prototype 91 est relié à au moins un modèle 92 de seuil et à un seul modèle 93 d'indicateur QoS. Le modèle SLA peut aussi inclure en option, comme illustré, au moins un modèle 94 de rapports à générer. Un modèle SLA 90 créé lors de l'étape S5 respecte donc la grammaire générique de la structure de modèle SLA, quelle que soit la technologie concernée par le modèle SLA. Les modèles SLA 90 enrichissent le référentiel 47 du procédé de contrôle de qualité pour différentes technologies, selon les besoins du fournisseur.
De même encore, la structure d'un modèle d'outils de collecte de données utilisables pour vérifier les critères SLA est décrite sous forme générique au moyen d'une grammaire de description d'outils SLA. Dans ce cas, la description générique signifie qu'elle est indépendante des technologies utilisées par les opérateurs et les équipementiers. La structure de modèle d'outils de collecte qui est décrite au moyen de la grammaire de description d'outils SLA permet de définir lors de l'étape S6 au moins un modèle 110 d'outils SLA. Ainsi, la création d'un modèle 110 d'outils SLA respecte la grammaire générique, quelle que soit la technologie, l'équipement et le modèle SLA concernés. Les modèles 110 d'outils SLA enrichissent le référentiel 47 du procédé de contrôle de qualité par des données permettant de configurer automatiquement un produit d'administration de façon à mettre en #uvre le contrôle de qualité des services.
Il est à noter qu'un modèle 110 d'outils SLA s'appuie sur l'infrastructure d'un service défini pour une technologie donnée avec des types de composants spécifiques. L'infrastructure de ce service est représentée sous forme d'un modèle de service dépendant des types d'équipements constituant son infrastructure. Ainsi, un modèle 110 d'outils SLA est totalement dépendant d'un modèle SLA 90 et d'un modèle 80 de service. En conséquence, un modèle 110 d'outils SLA ne peut être installé que si le modèle 90 de
contrat et le modèle 80 de service auquel il se rapporte ont déjà été installés dans le système d'administration.
En résumé, l'invention propose donc trois grammaires pour décrire les trois structures lors des étapes SI, S2 et S3 du procédé, à savoir : - une grammaire de modèle de service pour décrire la structure d'un modèle de service à fournir qui, dans le domaine des télécommunications, est une connexion de bout en bout utilisant une technologie donnée et des types d'équipements fournis par différents constructeurs. Cette grammaire peut par exemple définir des types de points terminaux aux deux bouts de la connexion et des paramètres, notamment des paramètres de trafic ; - une grammaire de modèle SLA pour décrire la structure d'un modèle de contrat passé entre un client et un opérateur de télécommunications, la description concernant un ensemble de critères SLA du contrat et, en option, un ensemble de modèles de rapports à générer ; et - une grammaire de description d'outils SLA pour décrire un modèle de configuration des outils utilisables pour vérifier la conformité du contrat. Ces outils peuvent être des outils de collecte d'indicateurs ou bien d'autres outils intervenant dans le procédé de contrôle de qualité. La description de la configuration de ces outils doit permettre de pré-configurer ces outils de manière automatique avec les éléments de configuration dont ils ont besoin lors de leur exécution.
Ces trois grammaires résultent d'un choix des données à traiter.
La description de la structure de ces grammaires est faite en langage unifié de modélisation UML (Unified Modeling Language) actuellement bien adapté à la description d'objets dans la technologie orientée objets. Les trois grammaires spécifiées en UML sont implémentées en langage XML sous la forme de trois fichiers. Le langage XML (eXtensible Markup Language) est un langage de description et d'échange de documents structurés. Il permet de décrire la structure logique de documents à l'aide d'un système de balises permettant de marquer les éléments qui composent la structure, et les relations entre ces éléments. Le langage XML distingue deux classes de documents : les documents bien formés et les documents valides. Un
document est dit bien formé lorsqu'il obéit aux règles syntaxiques du langage XML. Il peut donc être traité avec succès par un processeur adéquat, et notamment par un analyseur (parser) XML. Un document est dit valide lorsqu'il est bien formé et qu'il obéit en outre à une structure type définie explicitement dans une grammaire appelée DTD (Document Type Définition).
Le procédé de contrôle de qualité de service qui est représenté sur la figure 4 se poursuit par trois étapes S7, S8 et S9 illustré par des flèches et partant des trois modèles respectifs 80,90 et 110. Les étapes S7, S8 et S9 se rapportent à la construction notamment du service désiré 85, du contrat désiré 100 et d'au moins un outil de collecte 120 nécessaire au contrôle de la qualité définie par le contrat 100. En d'autres termes, les étapes S7, S8 et S9 permettent de construire plusieurs services 85, plusieurs contrats 100 et plusieurs outils de collecte 120 à partir des modèles respectifs 80,90 et 110.
Le service 85 contient des composants 86 et, optionnellement, des paramètres 87, pouvant par exemple inclure des paramètres de trafic dans le cas d'un service de télécommunication. Les composants 86 sont issus des modèles 81 de type de composant du modèle 80 de service tandis que les paramètres 87 sont issus du modèle de paramètre 82 du modèle 80. Le contrat 100 définit notamment : les critères SLA 101, construits à partir des prototypes de critère SLA respectifs 91 ; valeurs des seuils 102 issues d'au moins le modèle de seuil 92 ; et les indicateurs QoS 103 relatifs aux critères SLA 101 et construits à partir des modèles d'indicateur QoS respectifs 93. De même, les modèles 110 d'outils de collecte servent à définir des outils 120 de collecte des indicateurs QoS nécessaires au contrôle de la qualité du service défini par le contrat 100.
Le procédé de contrôle de la qualité du service ainsi défini inclut aussi : une étape S10 de collecte d'indicateurs QoS conformément aux indicateurs QoS 103 du contrat 100 et au moyen d'au moins un outil de collecte 120 ; une étape S11 de comparaison des indicateurs QoS avec les seuils correspondants 102 définis dans le contrat 100 ; et, selon l'option choisie, une étape S12 de rapports établis en l'occurrence selon les modèles 94 de rapport qui existent dans le modèle de contr at 90 et aussi contenus dans le
contrat 100 et non illustrés dans le contrat 100 pour des raisons de clarté des dessins. Le procédé illustré prend fin à l'étape S13.
La figure 5 illustre la structure d'un modèle 80 de service, qui met en oeuvre dans l'étape SI du procédé une grammaire de description d'un modèle de service. Le modèle 80 de service illustré comprend au moins un modèle de type de composant, en l'occurrence relatif aux divers types de composants 81 pouvant constituer l'infrastructure d'une connexion de télécommunication, et un modèle 82 de paramètre. À partir du modèle 80 de service est défini un service 85 en spécifiant les composants 86 et en donnant les paramètres 86 de configuration du trafic. Le modèle 80 d'un service de télécommunication 85 est décrit par une classe ServicePackage qui possède les attributs : # name désignant le nom du modèle de service ; # version désignant la version du modèle de service ; # serviceType désignant le type de service du modèle ; et # iconName désignant le nom de l'icône représentant un service.
La classe ServicePackage inclut les différents types de composants 81 utilisables pour le modèle de service 80. Ces types sont regroupés en trois catégories.
La première catégorie représente les points terminaux du service dans une classe EndPoints. Ces points représentent dans le réseau les composants d'entrée et de sortie du service. Lors de la création du service, ces composants devront être définis en nombre et en type tels que décrits dans le modèle. Ces points sont indispensables à la définition du service de télécommunication 85 choisi comme exemple.
Un canal de communication peut ainsi être créé selon tout mode de communication tel que défini plus haut ; il est constitué de n'importe quelle voie de transmission de données (spécifique à chaque mode de communication) à même de réaliser l'appel d'une fonctionnalité avec les paramètres associés, et la récupération de la ou des valeurs de retour résultant du traitement effectué par la fonctionnalité.
Dès lors que les canaux de communication sont créés, les composants peuvent communiquer directement entre eux. # Chargement et déchargement dynamique des composants Lorsqu'une interface importée a la propriété runtime , composant qui utilise cette interface demandera le chargement composant qui implémente cette interface, seulement lorsque composant aura besoin de la fonctionnalité associée à l'interface. Cette propriété runtime est ainsi une alternative à la propriété loadtime déjà décrite.
Cette gestion permet de déterminer précisément les propriétés l'implémentation de l'interface qui doit être chargée, en fonction paramètres dynamiques, qui ne sont pas connus lors du chargement du composant demandant la fonctionnalité.
Par exemple, un composant texte peut importer une interface codec pour décompresser les fichiers qu'il reçoit, ce composant texte pouvant recevoir plusieurs types de fichiers. Lors de la réception d'un fichier, le composant texte peut rechercher l'interface codec adaptée à la décompression de ce fichier, en fonction de son extension par exemple. Pour ce faire, il utilise la fonctionnalité Query() du gestionnaire de dépendances, en lui passant les paramètres de recherche.
Il peut ensuite donner l'ordre au gestionnaire de dépendances, à l'aide de la fonctionnalité Open(), de charger le composant. Il peut alors utiliser l'interface codec de ce composant pour décompresser le fichier.
Lorsque la décompression est terminée, le composant texte peut demander déchargement du composant codec utilisé.
II ainsi possible de charger dynamiquement un composant. Cette possibilité permet de ne charger des composants que lorsqu'ils sont nécessaires pour effectuer un traitement. Le composant peut ensuite être déchargé lorsque son traitement est terminé.
Selon un autre exemple, une application peut afficher une image lors de son chargement et ne plus avoir ensuite à traiter des images de ce format, ou qu'exceptionnellement.
Cette application peut donc charger dynamiquement le composant de traitement du format de l'image, lui demander de traiter fichier pour afficher l'image et ensuite décharger ce composant. Le composant n'est chargé en mémoire que lorsqu'il est strictement nécessaire, qui permet de partager les ressources mémoires entre les différents composants, en fonction de traitements à réaliser à un instant donné.
Cette méthode permet donc de réduire considérablement les ressources mémoire nécessaires.
Le gestionnaire de dépendances peut également gérer automatiquement le chargement et le déchargement de composants en fonction de leurs statistiques d'utilisation et des ressources memoire. Cette gestion devient alors complètement transparente pour le programmeur de l'application.
Le schéma de la figure 8 montre l'intérêt de la gestion dynamique des composants sur un système possédant peu de ressources mémoire. Dans cet exemple, l'application affiche deux images, une GIF et une JPEG. Chaque image est traitée de façon séquentielle, ce qui permet donc de charger et de décharger les composants dynamiquement.
Dans cet exemple, le fait de charger et décharger les composants dynamiquement permet de réduire la ressource mémoire maximum nécessaire.
En outre dans la plupart des cas, ce chargement et déchargement ne seront pas perceptibles en terme de performances.
En effet, les modules de composants ont une taille réduite (de l'ordre quelques centaines d'octets à quelques kilooctets). Leur chargement en memoire est donc une opération qui est réalisée très rapidement. En outre, la plupart des applications effectuent des traitements séquentiels et les informations en entrée sont souvent fournies par un utilisateur humain et les informations de sortie sont fournies à l'utilisateur.
Donc à l'échelle humaine, les quelques micro-secondes qui seront nécessaires pour charger et décharger un composant, ne seront même pas perceptibles ; dans le cas de l'exemple illustré par la figure 8, les opérations font selon la séquence suivante chargement d'une image (chargement du code de JPEG), affichage de cette image à l'écran, l'utilisateur, chargement d'une autre image (déchargement code JPEG et déchargement du code GIF), # affichage de cette autre image.
Les figures 5 et 6 montrent l'installation d'éclairage corres-
pondant à un troisième exemple de réalisation dans lequel la structure de base est la même que dans le premier exemple. L'installation d'éclairage selon le troisième exemple de réalisation comporte pour le même but que dans le premier exemple de réalisation, au moins une source lumineuse complémentaire 50 qui par comparaison avec la taille de l'élément guide de lumière 20 peut être considérée comme sensiblement ponctuelle. Il
s'agit par exemple de deux sources de lumière complémentaires 50 réali-
sées par de petites lampes à incandescence, de faible puissance électrique.
La puissance reçue par les lampes à incandescence 50 peut être par
exemple de l'ordre de 2 à 5 W. Les sources lumineuses 50, complémentai-
res peuvent comporter chaque fois un réflecteur 52 qui réfléchit la lumière émise. La lumière émise par les sources lumineuses 50 complémentaires est utilisée pour créer au moins un maximum accentué pour l'intensité
lumineuse dans la lumière émise globalement par l'installation d'éclairage.
Les sources lumineuses 50 complémentaires peuvent être installées de manière décalée par rapport à l'élément guide de lumière 20 au-dessus et
en dessous de celui-ci ou derrière cet élément 20.
Les figures 7 et 8 montrent un quatrième exemple de réali-
sation de l'installation d'éclairage. Cette installation d'éclairage comporte un élément photoémetteur 60, allongé en forme de source lumineuse. La source lumineuse 60 est de préférence un tube à décharge, notamment un tube néon. La source lumineuse 60 est par exemple de forme sensible- ment cylindrique et sa longueur dans la direction de l'axe longitudinal 61 est beaucoup plus importante que sa dimension dans la direction radiale par rapport à l'axe longitudinal 61. La source lumineuse 60 est entourée sur une partie de sa périphérie par un réflecteur 62 qui a également une forme au moins sensiblement cylindrique correspondant à la forme de la
source lumineuse 60. La lumière sort de manière répartie de la source lu-
mineuse 60, sur toute sa périphérie, suivant sa longueur et cette lumière est au moins en partie réfléchie par le réflecteur 62 pour sortir de
l'installation d'éclairage par la vitre 12. La lumière émise par la source lu-
mineuse 60 et celle réfléchie par réflecteur 62 donnent une répartition de
immédiat d'un foyer objet Fo d'un miroir récupérateur et concentrateur M de forme ellipsoï-
dale, qui fournit à son foyer image Fi l'image de la source S sous forme d'une tache lumineuse
possédant une répartition appropriée de la lumière au sein de cette tache. Une lentille conver-
gente L, par exemple plan-convexe, est disposée en aval du miroir M, de telle manière que son foyer objet FL coïncide avec le foyer image Fi du miroir elliptique M. De cette manière, la lentille L projette un faisceau de rayons sensiblement parallèles pour éclairer la route devant le véhicule, à travers une glace de protection G, cette glace étant lisse, c'est à dire non déviatrice
ou faiblement déviatrice.
De manière avantageuse, le miroir M est un miroir apte à engendrer par lui-même une tache lumineuse possédant un certain étalement en largeur, comme décrit dans les documents
FR-A-2 704 044 et FR-A-2 773 604 au nom de la Demanderesse.
Un cache fixe ou escamotable CA permet, de façon connue en soi, de venir occulter une partie de la tache lumineuse au voisinage du foyer FL de la lentille L, de manière à ce que
la lentille L projette sur la route un faisceau de croisement, délimité par une coupure supé-
rieure de configuration déterminée. Si le cache CA est escamotable, la position escamotée de
ce dernier laisse la tache lumineuse intacte, de sorte la lentille L projette sur la route un fais-
ceau de route sans coupure.
Le faisceau de croisement engendré lorsque le cache CA occulte une partie de la tache
lumineuse est un faisceau de croisement aux normes européennes, par exemple pour la circu-
lation à droite, et sa répartition est illustrée sur la Figure 3A. Cette Figure représente l'intersection par un écran perpendiculaire à l'axe optique du projecteur du faisceau obtenu à l'aide du projecteur que l'on vient de décrire, la ligne YY' représentant l'intersection de cet
écran avec un plan horizontal. On observe sur cette Figure une demicoupure Cg essentielle-
Section 10 -Liens en mode gelé Le passage en mode gelé signifie que : - non seulement l'utilisateur a validé le lien ajouté, mais de plus - la version courante de la page (vers laquelle pointe ledit lien ajouté au moment où la transition au mode gelé est effectuée) est stockée dans le système afin de garantir à
Selon un premier type connu, proposé par le brevet US 4 854 508, chaque roue de cisaillement comprend une pluralité de plaques- couteaux, de dimension axiale sensiblement égale à celle de la couronne- support, fixées sur la face périphérique de cette dernière par des moyens de fixation accessibles depuis les faces périphériques desdites plaques-couteaux.
Ce type de roue présente l'inconvénient suivant : les plaques- couteaux usées dont le pouvoir tranchant est devenu insuffisant ne peuvent pas être réutilisées après réaffûtage. En effet, si une réduction de la dimension radiale d'une plaque-couteau, après affûtage, est rattrapable par adjonction d'une cale entre la couronne-support et la plaque-couteau, une réduction de sa dimension axiale ne peut être compensée par un système similaire. Or, dans le cas le plus courant des broyeurs birotors, le découpage des déchets est assuré non seulement par le chevauchement des roues des deux rotors du broyeur (chevauchement qui dépend de la dimension radiale des roues et donc de celle des plaques-couteaux), mais aussi et surtout par la minimisation du jeu fonctionnel de cisaillement existant entre deux roues adjacentes (jeu dépendant des dimensions axiales des plaques- couteaux). Le changement fréquent des plaques-couteaux et l'impossibilité de restaurer et de réutiliser les plaques-couteaux usées alourdissent considérablement le coût de maintenance de ces broyeurs.
Selon un deuxième type de dispositif connu, proposé par le brevet US 4 901929, les joues latérales des couronnes-supports présentent chacune un épaulement sur lequel viennent reposer des couteaux, s'étendant radialement au- delà de la face périphérique de la couronne-support. Chaque couteau est rigidement fixé sur une joue latérale de la couronne-support par des moyens de fixation accessibles latéralement depuis des trous pratiqués dans le couteau situé en regard, sur l'autre joue latérale de la couronne-support. Contrairement au premier type de dispositif décrit, les organes de cisaillement de ce deuxième type, à savoir les couteaux, peuvent être désolidarisés de la roue, restaurés (affûtés), puis réutilisés, sous réserve de compenser, par des cales intercalées entre les joues latérales de la couronne-support et les couteaux, la diminution consécutive à l'affûtage de leur dimension axiale. Mais ce dispositif présente en contrepartie l'inconvénient suivant les moyens de fixation latéraux dudit couteau sur la couronne-support sont peu accessibles, du moins avec des outils conventionnels, de par leur agencement et leur position latérale sur la roue (lorsque la roue est montée sur son rotor, elle est bordée par deux roues voisines limitant l'espace libre latéralement). Le retrait d'un couteau en vue de sa réfection nécessite même parfois le démontage complet du rotor et de ses roues. Cette opération entraîne par conséquent une immobilisation longue et coûteuse du broyeur.