FR3077664A1 - Systeme d'elaboration d'un programme de signalisation ferroviaire et procede d'elaboration associe - Google Patents
Systeme d'elaboration d'un programme de signalisation ferroviaire et procede d'elaboration associe Download PDFInfo
- Publication number
- FR3077664A1 FR3077664A1 FR1850893A FR1850893A FR3077664A1 FR 3077664 A1 FR3077664 A1 FR 3077664A1 FR 1850893 A FR1850893 A FR 1850893A FR 1850893 A FR1850893 A FR 1850893A FR 3077664 A1 FR3077664 A1 FR 3077664A1
- Authority
- FR
- France
- Prior art keywords
- type
- data
- operator
- graphic element
- functional
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000011664 signaling Effects 0.000 title claims abstract description 52
- 238000000034 method Methods 0.000 title claims description 50
- PWPJGUXAGUPAHP-UHFFFAOYSA-N lufenuron Chemical compound C1=C(Cl)C(OC(F)(F)C(C(F)(F)F)F)=CC(Cl)=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F PWPJGUXAGUPAHP-UHFFFAOYSA-N 0.000 title description 2
- 230000000007 visual effect Effects 0.000 claims abstract description 75
- 238000004519 manufacturing process Methods 0.000 claims abstract description 18
- 238000010276 construction Methods 0.000 claims abstract description 10
- 230000004931 aggregating effect Effects 0.000 claims description 21
- 238000003860 storage Methods 0.000 claims description 10
- 238000004220 aggregation Methods 0.000 claims description 9
- 230000002776 aggregation Effects 0.000 claims description 9
- 238000000354 decomposition reaction Methods 0.000 claims description 6
- 230000006870 function Effects 0.000 claims description 5
- 238000002360 preparation method Methods 0.000 claims description 4
- 238000009434 installation Methods 0.000 claims description 3
- 230000015556 catabolic process Effects 0.000 claims 1
- 230000033772 system development Effects 0.000 claims 1
- 238000002513 implantation Methods 0.000 abstract description 2
- 230000010365 information processing Effects 0.000 description 9
- 230000001133 acceleration Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 101000879675 Streptomyces lavendulae Subtilisin inhibitor-like protein 4 Proteins 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 239000007943 implant Substances 0.000 description 1
- CNQCVBJFEGMYDW-UHFFFAOYSA-N lawrencium atom Chemical compound [Lr] CNQCVBJFEGMYDW-UHFFFAOYSA-N 0.000 description 1
- ORQBXQOJMQIAOY-UHFFFAOYSA-N nobelium Chemical compound [No] ORQBXQOJMQIAOY-UHFFFAOYSA-N 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B61—RAILWAYS
- B61L—GUIDING RAILWAY TRAFFIC; ENSURING THE SAFETY OF RAILWAY TRAFFIC
- B61L21/00—Station blocking between signal boxes in one yard
- B61L21/04—Electrical locking and release of the route; Electrical repeat locks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/34—Graphical or visual programming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44589—Program code verification, e.g. Java bytecode verification, proof-carrying code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/33—Intelligent editors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/38—Creation or generation of source code for implementing user interfaces
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Mechanical Engineering (AREA)
- Stored Programmes (AREA)
- Processing Or Creating Images (AREA)
- User Interface Of Digital Computer (AREA)
Abstract
Ce système (10) d'élaboration d'un programme de signalisation ferroviaire (11), comprend un module de programmation en langage textuel (12) pour la programmation, par au moins un utilisateur, d'au moins un opérateur informatique (14, 15, 16, 17), et une mémoire (18) pour le stockage du ou de chaque opérateur informatique (14, 15, 16, 17) programmé au moyen du module de programmation (12). Le système d'élaboration (10) comprend également un environnement visuel (50) pour la présentation, sous forme d'élément graphique fonctionnel, d'au moins un opérateur informatique (14, 15, 16, 17) stocké dans la mémoire (18), l'environnement visuel (50) étant adapté pour permettre la construction, par au moins un utilisateur, d'une représentation visuelle du programme de signalisation ferroviaire (11) à partir du ou de chaque élément graphique fonctionnel. Le système de production (10) comprend encore un module d'implantation (24) apte à implanter le programme de signalisation ferroviaire (11) en fonction de la représentation visuelle.
Description
(54) SYSTEME D'ELABORATION D'UN PROGRAMME D'ELABORATION ASSOCIE.
(57) Ce système (10) d'élaboration d'un programme de signalisation ferroviaire (11), comprend un module de programmation en langage textuel (12) pour la programmation, par au moins un utilisateur, d'au moins un opérateur informatique (14, 15, 16, 17), et une mémoire (18) pour le stockage du ou de chaque opérateur informatique (14, 15, 16, 17) programmé au moyen du module de programmation (12). Le système d'élaboration (10) comprend également un environnement visuel (50) pour la présentation, sous forme d'élément graphique fonctionnel, d'au moins un opérateur informatique (14, 15, 16, 17) stocké dans la mémoire (18), l'environnement visuel (50) étant adapté pour permettre la construction, par au moins un utilisateur, d'une représentation visuelle du programme de signalisation ferroviaire (11) à partir du ou de chaque élément graphique fonctionnel. Le système de production (10) comprend encore un module d'implantation (24) apte à implanter le programme de signalisation ferroviaire (11) en fonction de la représentation visuelle.
DE SIGNALISATION FERROVIAIRE ET PROCEDE
Système d’élaboration d’un programme de signalisation ferroviaire et procédé d’élaboration associé
La présente invention concerne un système d’élaboration d’un programme de signalisation ferroviaire, du type comprenant un module de programmation en langage textuel pour la programmation, par au moins un utilisateur, d’au moins un opérateur informatique, et une mémoire pour le stockage du ou de chaque opérateur informatique programmé au moyen du module de programmation. L’invention concerne également un procédé d’élaboration d’un programme de signalisation ferroviaire.
Les programmes de signalisation ferroviaire sont connus. Ils sont aptes à être exécutés par des systèmes de signalisation ferroviaire tels que le système décrit dans WO 2006/051355.
L’élaboration de ces programmes de signalisation ferroviaire sont soumis aux normes CENELEC 50128 et IEC 62279. Ces normes imposent un procédé de développement particulier pour des programmes de signalisation ferroviaire qualifiés de critiques dans l’objectif d’assurer un haut niveau de fiabilité de ces programmes.
Ces normes font la distinction entre deux types de développement pour les programmes de signalisation ferroviaire :
le développement logiciel, dans lequel les programmes sont produits en utilisant des langages textuels, et le développement algorithmique, dans lequel les programmes sont produits en utilisant des langages à environnement visuel tels que les diagrammes à boîtes fonctionnelles, les schémas à relais, ou les diagrammes de fonctions séquentielles.
Les normes CENELEC EN 50128 et CEI 62279 définissent ainsi, pour chacun de ces deux types de développement, les différentes étapes par lesquels doit passer le développement d’un programme et les livrables devant être fournis à chaque étape pour que le programme obtenu atteigne un niveau de sécurité prédéfini, ce niveau de sécurité pouvant aller de SILO pour le moins exigeant et jusqu’à SIL4 pour le plus exigeant.
A titre d’exemple, ces normes imposent, pour le développement logiciel d’un programme de niveau SIL4, que le développement de ce logiciel passe par huit étapes au cours desquelles doivent être produits vingt-quatre livrables. En comparaison, elles n’imposent que quatre étapes et huit livrables pour le développement algorithmique d’un programme. Cette différence s’explique par le fait que le développement algorithmique utilise des langages moins générateurs d’erreurs et demande moins d’activités et moins de produits livrés.
Il est ainsi beaucoup plus aisé et moins coûteux de produire un programme de signalisation ferroviaire en utilisant un développement algorithmique. Toutefois, en dépit de ces avantages évidents, le développement algorithmique est très peu utilisé pour les programmes de signalisation ferroviaire. La raison vient du fait que les langages utilisés pour le développement algorithmique sont habituellement ceux définis par la norme CEI 61131-3. Or, ces langages sont des langages de très bas niveau ne fournissant que des opérations basiques, telles que des opérations logiques, des opérations arithmétiques ou des fonctions temporelles, ne pouvant agir et produire que des types de données basiques, tels que les types booléen, entier signé ou non signé, réel en virgule flottante et chaînes de caractères. Ces langages ne présentent ainsi pas l’expressivité que l’on peut avoir avec des langages textuels, de sorte qu’il n’y a aucune garantie à ce que des programmes de signalisation ferroviaire puissent être produits en utilisant l’un quelconque de ces langages. En outre, quand bien même une telle élaboration serait possible, elle serait très complexe à réaliser et il serait difficile de tester les programmes ainsi obtenus.
Un langage à environnement visuel est également connu de WO 00/60458. Toutefois, ce langage ne présente pas l’expressivité suffisante pour pouvoir être utilisé aisément dans l’élaboration de programmes de signalisation ferroviaire.
Les programmes de signalisation ferroviaires sont donc habituellement produits intégralement en utilisant des langages textuels. Or, une telle méthode d’élaboration prend un temps considérable en raison du grand nombre d’activité à réaliser et de livrables à produire pour assurer la fiabilité et la qualité du programme. De ce fait, les erreurs dans les spécifications du programme ne sont vues que très tardivement et sont coûteuses à corriger.
Un objectif de l’invention est ainsi de réduire les coûts et d’accélérer l’élaboration de programmes de signalisation ferroviaire, tout en maintenant un haut niveau de sécurité des programmes ainsi produits.
A cet effet, l’invention a pour objet un système d’élaboration du type précité, dans lequel le système d’élaboration comprend également un environnement visuel pour la présentation, sous forme d’élément graphique fonctionnel, d’au moins un opérateur informatique stocké dans la mémoire, l’environnement visuel étant adapté pour permettre la construction, par au moins un utilisateur, d’une représentation visuelle du programme de signalisation ferroviaire à partir du ou de chaque élément graphique fonctionnel, le système de production comprenant encore un module d’implantation apte à implanter le programme de signalisation ferroviaire en fonction de la représentation visuelle.
Selon des modes de réalisation particuliers de l’invention, le système d’élaboration présente également l’une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toute(s) combinaison(s) techniquement possible(s) :
- l’environnement visuel permet la duplication du ou de chaque élément graphique fonctionnel, de manière à former un élément graphique dupliqué ;
- le ou chaque opérateur informatique est configuré pour traiter au moins un type prédéfini de données entrantes et produire au moins un type prédéterminé de données sortantes, le ou chaque élément graphique fonctionnel présentant, pour le ou chaque type prédéfini, une entrée respective pour l’alimentation de l’opérateur informatique avec au moins une donnée entrante dudit type prédéfini, et, pour le ou chaque type prédéterminé, une sortie respective pour la fourniture, par l’opérateur informatique, d’au moins une donnée sortante dudit type prédéterminé, et l’environnement visuel comprend au moins un élément graphique de flux pour raccorder les entrées et les sorties du ou de chaque élément graphique fonctionnel de manière à construire la représentation visuelle ;
- l’environnement visuel est adapté pour empêcher le raccordement d’entrées correspondant à un type prédéfini à des sorties correspondant à un type prédéterminé différent dudit type prédéfini et qui n’englobe ni ne constitue un sous-type dudit type prédéfini ;
- chaque opérateur présente, pour chaque type de données entrantes et sortantes qu’il est configuré pour traiter, respectivement pour produire, une cardinalité dudit type de données définissant le nombre de données dudit type que l’opérateur est adapté pour traiter, respectivement pour produire, à chaque instance dudit opérateur ;
- au moins un opérateur présente une cardinalité fixe pour au moins un type de données entrantes ou sortantes qu’il est configuré pour traiter, respectivement pour produire, et l’environnement visuel est adapté pour empêcher le raccordement, à la ou chaque entrées et/ou à la ou chaque sortie à laquelle est associée une cardinalité fixe, d’un nombre d’éléments graphiques de flux différent de cette cardinalité ;
- au moins un opérateur présente une cardinalité variable pour au moins un type de données entrantes ou sortantes qu’il est configuré pour traiter, respectivement pour produire ;
- l’environnement visuel comprend au moins un élément graphique agrégateur pour l’agrégation de plusieurs données de types basiques en au moins une donnée de type complexe, l’environnement visuel comprenant également au moins un élément graphique de flux pour le raccordement d’au moins une entrée et/ou d’une sortie de l’élément graphique agrégateur à au moins une sortie, respectivement à au moins une entrée d’un élément graphique fonctionnel ;
- l’élément graphique agrégateur présente, pour chaque type basique, une cardinalité dudit type basique définissant le nombre de données dudit type basique que l’élément graphique agrégateur est adapté pour agréger au sein de la donnée de type complexe, la cardinalité associée à au moins un desdits types basiques étant variable ; et
- l’environnement visuel comprend au moins un élément graphique décomposeur pour la décomposition d’au moins une donnée de type complexe en plusieurs données de types basiques, l’environnement visuel comprenant également au moins un élément graphique de flux pour le raccordement d’une entrée et/ou d’au moins une sortie de l’élément graphique décomposeur à au moins une sortie, respectivement à au moins une entrée, d’un élément graphique fonctionnel.
L’invention a également pour objet un procédé d’élaboration d’un programme de signalisation ferroviaire au moyen d’un système d’élaboration tel que défini ci-dessus, comprenant les étapes suivantes :
- programmation, par un premier utilisateur, au moyen du module de programmation, d’une pluralité d’opérateurs informatiques,
- stockage dans la mémoire de chaque opérateur informatique produit,
- présentation dans l’environnement visuel de chaque opérateur informatique stocké, sous forme d’un élément graphique fonctionnel,
- construction d’une représentation visuelle du programme de signalisation ferroviaire, par un deuxième utilisateur, dans l’environnement visuel, à partir des éléments graphiques fonctionnels, et
- implantation du programme de signalisation ferroviaire à partir de la représentation visuelle, par le module d’implantation.
Selon des modes de réalisation particuliers de l’invention, le procédé d’élaboration présente également l’une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toute(s) combinaison(s) techniquement possible(s) :
- le ou chaque opérateur informatique est configuré pour traiter au moins un type prédéfini de données entrantes et produire au moins un type prédéterminé de données sortantes, et le ou chaque élément graphique fonctionnel présente, pour le ou chaque type prédéfini, une entrée respective pour l’alimentation de l’opérateur informatique avec au moins une donnée entrante dudit type prédéfini, et, pour le ou chaque type prédéterminé, une sortie respective pour la fourniture, par l’opérateur informatique, d’au moins une donnée sortante dudit type prédéfini ;
- l’étape de construction de la représentation visuelle comprend une sous-étape de raccordement, par le deuxième utilisateur, dans l’environnement visuel, des sorties de plusieurs éléments graphiques fonctionnels de bas niveau aux entrées d’un élément graphique agrégateur, et la présentation, par l’environnement visuel, d’une représentation d’un flux de données de type complexe représentant un flux de données de type complexe résultant de l’agrégation de données sortantes produites par le ou les opérateurs informatiques représentés par lesdits éléments graphiques fonctionnels de bas niveau ;
- l’étape de construction de la représentation visuelle comprend une sous-étape de raccordement, par le deuxième utilisateur, dans l’environnement visuel, d’une sortie d’un élément graphique fonctionnel de haut niveau à une entrée d’un élément graphique décomposeur, et la présentation, par l’environnement visuel, de représentations de flux de données de types basiques représentant des flux de données de types basiques résultant de la décomposition d’une donnée sortante produite par l’opérateur informatique représenté par l’élément graphique fonctionnel de haut niveau ;
- l’étape de programmation est mise en œuvre en application des normes CENELEC EN 50128 et CEI 62279 ; et
- l’étape de construction de la représentation visuelle comprend une sous-étape de duplication d’un élément graphique fonctionnel, de manière à former un élément graphique dupliqué, suivie d’une sous-étape de raccordement d’au moins une entrée ou d’au moins une sortie dudit élément graphique dupliqué à une sortie, respectivement une entrée, d’un autre élément graphique fonctionnel.
D’autres caractéristiques et avantages de l’invention apparaîtront à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple et faite en se référant aux dessins annexés, dans lesquels :
la Figure 1 est une représentation schématique d’un système d’élaboration selon l’invention, la Figure 2 est un exemple de représentation graphique d’un programme de signalisation ferroviaire élaboré au moyen du système d’élaboration de la Figure 1, et la Figure 3 est diagramme en blocs d’un procédé d’élaboration d’un programme de signalisation ferroviaire mettant en œuvre le système d’élaboration de la Figure 1.
Le système d’élaboration 10 représenté sur la Figure 1 est destiné à l’élaboration d’un programme de signalisation ferroviaire 11. A cet effet, le système 10 comprend un premier module 12 de programmation en langage textuel pour la programmation, par au moins un utilisateur, d’au moins un opérateur informatique 14, 15, 16, 17, une mémoire 18 pour le stockage du ou de chaque opérateur informatique 14, 15, 16, 17 programmé au moyen du module de programmation 12, un deuxième module 20 de programmation en langage graphique pour la construction, par un utilisateur, d’une représentation visuelle 22 (Figure 2) du programme de signalisation ferroviaire 11, un module d’implantation 24, apte à implanter le programme de signalisation ferroviaire 11 en fonction de la représentation visuelle 22, et un support de stockage 26 pour le stockage du programme de signalisation ferroviaire 11 achevé.
Le premier module de programmation 12 est destiné à la programmation, en langage textuel, d’opérateurs informatiques configurés pour traiter au moins une donnée entrante et produire au moins une donnée sortante. A cet effet, le module de programmation 12 comprend, de manière connue, un équipement 30 comportant une unité de traitement d’informations 32 et une interface homme-machine 34, l’unité de traitement d’informations 32 comprenant un processeur 36 et une mémoire 38 associée au processeur 36, la mémoire 38 stockant un logiciel de programmation en langage textuel 39 apte à être exécuté par le processeur 36 de manière à présenter à un utilisateur, via l’interface homme-machine 34, une interface de programmation en langage textuel. Le logiciel de programmation 39 comprend typiquement un logiciel de programmation en langage C, C+-1-, C#, Ada ou autre. Il est avantageusement couplé à un logiciel de gestion de projet pour le développement logiciel (non représenté) adapté pour imposer aux utilisateurs du premier module de programmation 12 les phases et les livrables définis par les normes CENELEC EN 50128:2011 et CEI 62279:2015 en cas de développement logiciel.
La mémoire 18 stocke une pluralité d’opérateurs 14, 15, 16, 17 programmés au moyen du module de programmation 12 de sorte à être insensibles au contexte.
Chacun de ces opérateurs 14, 15, 16, 17 est configuré pour traiter au moins un type prédéfini de données entrantes et produire au moins un type prédéterminé de données sortantes. En d’autres termes, chaque opérateur 14, 15, 16, 17 est configuré pour traiter au moins une donnée entrante d’au moins un type prédéfini, et pour produire au moins une donnée sortante d’au moins un type prédéterminé. En particulier, chacun des opérateurs 14, 15, 16, 17 est configuré pour ne traiter que des données entrantes du ou de chaque type prédéfini et ne produire que des données sortantes du ou de chaque type prédéterminé.
Chaque opérateur 14, 15, 16, 17 présente, pour chaque type de données entrantes et sortantes qu’il est configuré pour traiter, respectivement pour produire, une cardinalité dudit type de données. Cette cardinalité définit le nombre de données dudit type que l’opérateur 14, 15, 16, 17 est adapté pour traiter, respectivement pour produire, à chaque instance dudit opérateur 14, 15, 16, 17.
Ces opérateurs 14, 15, 16, 17 comprennent ici un premier opérateur 14 configuré pour traiter quatre types prédéfinis de données entrantes et produire un unique type prédéterminé de données sortantes. Le premier opérateur 14 est, par exemple, un opérateur de calcul d’accélération linéaire dont les types prédéfinis de données entrantes sont constitués par :
un type vitesse linéaire courante, un type vitesse linéaire précédente, un type date de production de la vitesse, et un type période de calcul ;
et dont la donnée sortante est constituée par :
un type accélération linéaire.
L’opérateur 14 a en particulier une cardinalité fixe pour chacun de ces types, c’està-dire que l’opérateur 14 est configuré pour ne traiter ou ne produire qu’un nombre prédéfini de données de chacun de ces types à chacune de ses instances. Cette cardinalité est typiquement [1, 1], c’est-à-dire que l’opérateur 14 est configuré pour ne traiter ou ne produire qu’une seule donnée de chacun de ces types à chacune de ses instances.
Dans l’exemple représenté, les opérateurs 14, 15, 16, 17 comprennent également un deuxième et un troisième opérateurs 15, 16 configurés chacun pour traiter un unique type prédéfini de données entrantes et produire un unique type prédéterminé de données sortantes.
Chacun des deuxième et troisième opérateurs 15, 16 a en particulier une cardinalité fixe pour son type prédéfini de données entrantes, et une cardinalité variable pour son type prédéterminé de données sortante, c’est-à-dire que chacun des deuxième et troisième opérateurs 15, 16 est configuré pour ne traiter, à chacune de ses instances, qu’un nombre prédéfini de données du type prédéfini, mais est adapté pour produire un nombre variable de données du type prédéterminé.
L’opérateur 15 est par exemple un opérateur de duplication de vitesse dont le type prédéfini de données entrantes est constitué par un type vitesse dont la cardinalité associée est [1, 1], c’est-à-dire que l’opérateur 15 est configuré pour ne traiter qu’une seule donnée de ce type à chacune de ses instances, et dont le type prédéterminé de données sortantes est constitué par un type vitesse dont la cardinalité associée est [1, +°°[, c’est-à-dire que l’opérateur 15 est configuré pour produire d’une seule à une multitude de données de ce type à chacune de ses instances.
Le type vitesse est un type englobant les types vitesse linéaire courante et vitesse linéaire précédente. En d’autres termes, les types vitesse linéaire courante et vitesse linéaire précédente sont des sous-types du type vitesse, c’est-à-dire que toute donnée de type vitesse linéaire courante et vitesse linéaire précédente constitue également une donnée de type vitesse.
L’opérateur 16 est par exemple un opérateur de duplication de date dont le type prédéfini de données entrantes est constituée par un type date dont la cardinalité associée est [1, 1], c’est-à-dire que l’opérateur 16 est configuré pour ne traiter qu’une seule donnée de ce type à chacune de ses instances, et dont le type prédéterminé de données sortantes est constituée par un type date dont la cardinalité est [1, +°°[, c’est-àdire que l’opérateur 16 est configuré pour produire d’une seule à une multitude de données de ce type à chacune de ses instances
Le type date est un type englobant le type date de production de la vitesse. En d’autres termes, le type date de production de la vitesse est un sous-types du type date, c’est-à-dire que toute donnée de type date de production de la vitesse constitue également une donnée de type date.
Dans l’exemple représenté, les opérateurs 14, 15, 16, 17 comprennent également un quatrième opérateur 17 configuré pour traiter deux types prédéfinis de données entrantes et produire deux types prédéterminés de données sortantes.
Le quatrième opérateur 17 a en particulier une cardinalité fixe pour chacun de ces types, c’est-à-dire que l’opérateur 17 est configuré pour ne traiter ou ne produire qu’un nombre prédéfini de données de chacun de ces types à chacune de ses instances.
L’opérateur 17 est par exemple un opérateur de calcul de vitesse linéaire dont les types prédéfinis de données entrantes sont constitués par :
un type configuration d’odomètre dont la cardinalité associée est [1, 1], c’està-dire que l’opérateur 17 est configuré pour ne traiter qu’une seule donnée de ce type à chacune de ses instances, et un type mouvement d’odomètre dont la cardinalité associée est [5, 5], c’està-dire que l’opérateur 17 est configuré pour traiter obligatoirement cinq données de ce type à chacune de ses instances, et dont les types prédéterminés de données sortantes sont constituées par :
un type vitesse linéaire dont la cardinalité associée est [1, 1 ], c’est-à-dire que l’opérateur 17 est configuré pour ne traiter qu’une seule donnée de ce type à chacune de ses instances, et un type date de production dont la cardinalité associée est [1, 1], c’est-à-dire que l’opérateur 17 est configuré pour ne traiter qu’une seule donnée de ce type à chacune de ses instances,.
Le type vitesse linéaire est un type englobant les types vitesse linéaire courante et vitesse linéaire précédente. Par ailleurs, le type vitesse linéaire est un sous-type du type vitesse.
Le type date de production est quant à lui un sous-type du type date.
Le deuxième module de programmation 20 comprend un équipement 40 comportant une unité de traitement d’informations 42 et une interface homme-machine 44, l’unité de traitement d’informations 42 comprenant un processeur 46 et une mémoire 48 associée au processeur 46, la mémoire 48 stockant un logiciel de programmation en langage graphique 49 apte à être exécuté par le processeur 46 de manière à présenter à un utilisateur, via l’interface homme-machine 44, un environnement visuel 50 pour la présentation, sous forme d’élément graphique fonctionnel 52, 53, 54, 55, 56, 57 (Figure 2) par exemple constitués par des blocs, des opérateurs informatiques 14, 15, 16, 17 stockés dans la mémoire 18.
Dans l’exemple représenté, l’équipement 40 est différent de l’équipement 30 du premier module de programmation. En variante (non représentée), les équipements 30 et 40 sont confondus, de même que les unités de traitement d’informations 32 et 42 et les interfaces homme-machine 34, 44. En variante encore, seules les unités de traitement d’informations 32 et 42 sont confondues, lesdites unités de traitement d’informations 32 et 42 étant constituées par une unité de traitement d’informations partagée entre les premier et deuxième modules de programmation 12, 20.
En référence à la Figure 2, les éléments graphiques fonctionnels 52, 53, 54, 55, 56, 57 sont au nombre de six, dont un premier élément graphique fonctionnel 52 présentant une première instance du premier opérateur 14, un deuxième élément graphique fonctionnel 53 présentant une deuxième instance du premier opérateur 14, un troisième élément graphique fonctionnel 54 présentant une première instance du deuxième opérateur 15, un quatrième élément graphique fonctionnel 55 présentant une instance du troisième opérateur 16, un cinquième élément graphique fonctionnel 56 présentant une instance du quatrième opérateur 17, et un sixième élément graphique fonctionnel 57 présentant une deuxième instance du deuxième opérateur 15.
Chaque élément graphique fonctionnel 52, 53, 54, 55, 56, 57 présente, pour le ou chaque type prédéfini de données entrantes que l’opérateur informatique 14, 15, 16, 17 correspondant est configuré pour traiter, une entrée 58, 59, 60, 61, 62, 63, 64, 65 respective, pour l’alimentation dudit opérateur informatique 14, 15, 16, 17 correspondant avec au moins une donnée entrante dudit type prédéfini. Chaque élément graphique fonctionnel 52, 53, 54, 55, 56, 57 présente également, pour le ou chaque type prédéterminé de données sortantes que l’opérateur informatique 14, 15, 16, 17 correspondant est configuré pour produire, une sortie 70, 71, 72, 73, 74 respective, pour la fourniture, par ledit opérateur informatique 14, 15, 16, 17 correspondant, d’au moins une donnée sortante dudit type prédéterminé.
Ainsi, le premier opérateur 14 étant configuré pour traiter des données entrantes de quatre types prédéfinis et pour produire des données sortantes d’un unique type prédéterminé, les éléments graphiques fonctionnels 52, 53 correspondant comprennent chacun quatre entrées 62, 63, 64, 65, correspondant chacune à un desdits types prédéfinis, et une unique sortie 74 correspondant au type prédéterminé. L’entrée 62 correspond typiquement au type période de calcul, l’entrée 63 correspond typiquement au type vitesse linéaire précédente, l’entrée 64 correspond typiquement au type date de production de la vitesse, et l’entrée 65 correspond typiquement au type vitesse linéaire courante.
Par ailleurs, les deuxième et troisième opérateurs 15, 16 étant chacun configurés pour traiter des données entrantes d’un unique type prédéfini et pour produire des données sortantes d’un unique type prédéterminé, les éléments graphiques fonctionnels 54, 55, 57 correspondant comprennent chacun une unique entrée 60, 61 correspondant audit type prédéfini, et une unique sortie 72, 73 correspondant audit type prédéterminé. L’entrée 60 et la sortie 72 des éléments graphiques fonctionnels 54, 57 correspondent typiquement chacune au type vitesse. L’entrée 61 et la sortie 73 de l’élément graphique fonctionnel 55 correspondent typiquement chacune au type date.
Enfin, le quatrième opérateur 17 étant configuré pour traiter des données entrantes de deux types prédéfinis et pour produire des données sortantes de deux types prédéterminés, l’élément graphique fonctionnel 56 correspondant comprend deux entrées 58, 59, correspondant chacune à un desdits types prédéfinis, et deux sorties 70, 71 correspondant chacune à un desdits types prédéterminés. L’entrée 58 correspond typiquement au type configuration d’odomètre, l’entrée 59 correspond typiquement au type mouvement d’odomètre, la sortie 70 correspond typiquement au type vitesse linéaire, et la sortie 71 correspond typiquement au type date de production.
Le logiciel de programmation en langage graphique 49 est également configuré pour permettre la duplication des éléments graphiques fonctionnels 52, 53, 54, 55, 56, 57, de manière à produire des éléments graphiques dupliqués tels que l’élément graphique 53, qui consiste en une duplication de l’élément graphique fonctionnel 52, et l’élément graphique 57, qui consiste en une duplication de l’élément graphique fonctionnel 54.
Le logiciel de programmation en langage graphique 49 est encore configuré pour présenter, dans l’environnement visuel 50, des éléments graphiques agrégateurs 80 (un seul étant ici présenté), typiquement sous forme de blocs, représentant chacun l’agrégation de plusieurs types de données basiques en un type données complexe, et des éléments graphiques décomposeurs 82 (un seul étant ici présenté), typiquement sous forme de blocs, représentant chacun la décomposition d’un type données complexe en plusieurs types de données basiques. Il convient de comprendre que les termes « basique » et « complexe » employés ici sont utilisés simplement dans un sens relatif l’un par rapport à l’autre, un type de données qualifié de « complexe » consistant en l’agrégation de plusieurs types de données qualifiés en comparaison de « basiques ».
Chaque élément graphique agrégateur 80 comprend une pluralité d’entrées 84, 85 pour l’alimentation de l’agrégateur 80 avec des données de types basiques à agréger, et une unique sortie 90 pour la fourniture d’au moins une donnée de type complexe résultant de l’agrégation des données de types basiques. L’élément graphique agrégateur comprend en particulier une entrée 84, 85 respective pour chacun desdits types basiques.
Chaque élément graphique agrégateur 80 présente, pour chaque type de données basique, une cardinalité dudit type de données. Cette cardinalité définit le nombre de données dudit type basique que l’élément graphique agrégateur 80 est adapté pour agréger au sein de la donnée de type complexe. De préférence, pour au moins un type de données basique, la cardinalité associée à ce type est variable, c’est-à-dire que l’élément graphique agrégateur 80 est adapté pour agréger au sein de la donnée de type complexe un nombre variable de données dudit type basique.
Chaque élément graphique décomposeur 82 comprend une unique entrée 86 pour l’alimentation du décomposeur 82 avec au moins une donnée de type complexe à décomposer, et une pluralité de sorties 105, 106, 107, 108, 109 pour la fourniture de données de types basiques résultant de de la décomposition de la donnée de type complexe. L’élément graphique décomposeur 82 comprend en particulier une sortie 105, 106, 107, 108, 109 respective pour chacun desdits types basiques.
Chaque élément graphique décomposeur 82 présente, pour chaque type de données basique, une cardinalité dudit type de données. Cette cardinalité définit le nombre de données dudit type basique que l’élément graphique décomposeur 82 est adapté pour produire par désagrégation de la donnée de type complexe. De préférence, pour au moins un type de données basique, la cardinalité associée à ce type est variable, c’est-à-dire que l’élément graphique décomposeur 82 est adapté pour décomposer une donnée entrante de type complexe en un nombre variable de données dudit type basique.
Le logiciel de programmation graphique 49 est enfin configuré pour que l’environnement visuel 50 permette le raccordement, par un utilisateur, des entrées 58, 59, 60, 61, 62, 63, 64, 65, 84, 85, 86 et des sorties 70, 71, 72, 73, 74, 90, 105, 106, 107, 108, 109 des différents éléments graphiques 52, 53, 54, 55, 56, 57, 80, 82 de manière à construire la représentation visuelle 22 du programme de signalisation ferroviaire 11. A cet effet, le logiciel de programmation graphique 49 est configuré pour que l’environnement visuel 50 permette la manipulation d’éléments graphiques de flux 100, ..., 121, typiquement sous forme de flèches, représentant chacun un flux de données d’un type donné et aptes à raccorder les entrées 59, 60, 61, 62, 63, 64, 65, 84, 85, 86 et les sorties 70, 71,72, 73, 74, 90, 105, 106, 107, 108, 109 des différents éléments graphiques 52, 53, 54, 55, 56, 57, 80, 82.
Le logiciel de programmation en langage graphique 49 est en particulier configuré de sorte que ce raccordement se fasse de manière à respecter les types de données correspondant auxdites entrées 59, 60, 61,62, 63, 64, 65, 84, 85, 86 et sorties 70, 71,72, 73, 74, 90, 105, 106, 107, 108, 109 et à respecter la cardinalité de chaque opérateur 14, 15, 16, 17 pour chaque type. Le logiciel de programmation en langage graphique 49 est ainsi configuré de sorte que l’environnement visuel 50 empêche le raccordement d’éléments graphiques de flux 100, ..., 121 représentant des flux de données de types donnés à des entrées 59, 60, 61, 62, 63, 64, 65, 84, 85, 86 ou à des sorties 70, 71, 72, 73, 74, 90, 105, 106, 107, 108, 109 ne correspondant pas à ces types, et donc empêche notamment le raccordement d’entrées 59, 60, 61,62, 63, 64, 65, 84, 85, 86 correspondant à un type prédéfini à des sorties 70, 71, 72, 73, 74, 90, 105, 106, 107, 108, 109 correspondant à un type prédéterminé différent dudit type prédéfini et qui ni n’englobe ni constitue un sous-type dudit type prédéfini. Le logiciel de programmation en langage graphique 49 est également configuré de sorte que l’environnement visuel 50 empêche le raccordement aux entrées 59, 60, 61, 62, 63, 64, 65, 84, 85, 86 et aux sorties 70, 71, 72, 73, 74, 90, 105, 106, 107, 108, 109 auxquelles sont associées une cardinalité fixe d’un nombre d’éléments graphiques de flux 100, ..., 121 différent de cette cardinalité.
Ainsi, le logiciel de programmation en langage graphique 49 est configuré pour ne permettre le raccordement :
aux entrées 65 des éléments graphiques 52, 53 que de sorties correspondant à des types vitesse linéaires, c’est-à-dire les sorties 70 et 72 des éléments graphiques 56 et 54 ;
aux entrées 64 des éléments graphiques 52, 53 que de sorties correspondant à des types dates de production de vitesses, c’est-à-dire les sorties 71 et 73 des éléments graphiques 56 et 55 ;
à l’entrée 60 de l’élément graphique 54 que de sorties correspondant à des types vitesses, c’est-à-dire à la sortie 70 de l’élément graphique 56 ; et à l’entrée 61 de l’élément graphique 55 que de sorties correspondant à des types dates, c’est-à-dire à la sortie 71 de l’élément graphique 56.
Le logiciel de programmation en langage graphique 49 est également configuré pour ne permettre le raccordement que d’un unique élément graphique de flux 100, ..., 121 aux entrées 58, 60, 61, 62, 63, 64, 65 et aux sorties 70, 71, 74, pour obliger le raccordement de cinq éléments graphiques de flux 100, ..., 121 à l’entrée 59, et pour permettre le raccordement d’un nombre illimité d’éléments graphiques de flux 100, ..., 121 aux sorties 72, 73.
De retour à la Figure 1, le logiciel de programmation graphique 49 est de préférence, comme représenté, couplé à un logiciel de gestion de projet pour le développement applicatif 120, lui aussi stocké dans la mémoire 48 et apte à être exécuté par le processeur 46, ce logiciel 120 étant adapté pour imposer aux utilisateurs du deuxième module de programmation 20 les phases et les livrables définis par les normes CENELEC EN 50128:2011 et CEI 62279:2015 en cas de développement applicatif.
Le module d’implantation 24 est typiquement constitué par un compilateur apte à compiler la représentation visuelle 22 en un langage exécutable par un processeur d’un système de signalisation ferroviaire, par exemple en langage machine, de manière à obtenir le programme de signalisation ferroviaire 11. En variante (non représentée), le module d’implantation 24 est constitué par un interpréteur apte à exécuter le programme de signalisation ferroviaire 11 directement à partir de la représentation visuelle 22, sans conversion de ladite représentation visuelle 22 en un autre langage.
Le module d’implantation 24 est de préférence intégré dans l’équipement 40 et est typiquement réalisé sous la forme d’un logiciel stocké dans la mémoire 48 de l’unité de traitement d’informations 42 et exécutable par le processeur 46.
Le support de stockage 26 est typiquement formé par un support de stockage amovible monté sur l’équipement 40, par exemple une clef USB. En variante (non représentée), le support de stockage 26 est constitué par une mémoire distante accessible par l’équipement 40 via un réseau informatique. En variante encore (non représentée), le support de stockage 26 est constitué par une mémoire interne de l’équipement 40.
Un procédé 200 d’élaboration d’un programme de signalisation ferroviaire au moyen du système d’élaboration 10 va maintenant être décrit, en référence à la Figure 3.
Tout d’abord, au cours d’une première étape 210 de programmation, un premier utilisateur, typiquement un ingénieur logiciel, programme, au moyen du module de programmation 12, une pluralité d’opérateurs informatiques, dont les opérateurs informatiques 14, 15, 16, 17, chacun desdits opérateurs informatiques étant configuré pour traiter au moins une donnée entrante et produire au moins une donnée sortante.
Cette programmation est effectuée en application des normes CENELEC EN 50128 et CEI 62279, c’est-à-dire en respectant les phases et les livrables définies par ces normes pour le développement logiciel.
Ces opérateurs informatiques sont ensuite stockés dans la mémoire 18, au cours d’une deuxième étape 220 de stockage.
Puis, lors d’une troisième étape 230 de présentation, chaque opérateur informatique stocké dans la mémoire 18 est présenté à un deuxième utilisateur, typiquement un ingénieur système, dans l’environnement visuel 50, sous forme d’un élément graphique fonctionnel, chaque élément graphique fonctionnel présentant au moins une entrée pour l’alimentation de l’opérateur informatique correspondant avec au moins une donnée entrante d’un type prédéfini, et au moins une sortie pour la fourniture, par l’opérateur informatique correspondant, d’au moins une donnée sortante d’un type prédéterminé. Cette étape 230 inclut notamment la présentation des opérateurs 14, 15, 16, 17 sous forme des éléments graphiques fonctionnels 52, 54, 55, 56.
Ensuite, lors d’une quatrième étape 240 de construction, le deuxième utilisateur construit la représentation visuelle 22 du programme de signalisation ferroviaire par raccordement, dans l’environnement visuel, des entrées et des sorties des éléments graphiques fonctionnels.
Tout d’abord, lors d’une première sous-étape 241 de duplication, le deuxième utilisateur duplique les éléments graphiques fonctionnels 52, 54 pour former respectivement les éléments graphiques fonctionnels 53, 57.
Ensuite, lors d’une deuxième sous-étape 242 d’adjonction, le deuxième utilisateur ajoute l’élément graphique agrégateur 80 et l’élément graphique décomposeur 82.
Puis, lors d’une troisième sous-étape 243 de raccordement des entrées de l’élément graphique agrégateur 80, le deuxième utilisateur raccorde au moyen d’éléments graphiques de flux 119, 120 les sorties 74 des éléments graphiques fonctionnels 52 et 53 aux entrées 84, 85 de l’élément graphique agrégateur 80 ; le type des données sortantes de l’opérateur 14 est de ce fait considéré, par l’élément graphique agrégateur 80, comme un type basique : les éléments graphiques fonctionnels 52 et 53 constituent alors, pour cet élément graphique agrégateur 80, des éléments graphiques fonctionnels de bas niveau.
L’environnement visuel 50 présente alors, lors d’une quatrième sous-étape 244 de présentation de la sortie 90 de l’élément graphique agrégateur, une représentation d’un flux de données de type complexe, constituée ici par l’élément graphique de flux 121, représentant un flux de données de type complexe résultant de l’agrégation des données sortantes produites par les instances de l’opérateur informatique 14. Ce type complexe consiste ici en un type accélération consolidée composé de l’agrégation des types accélération linéaire produits par les première et deuxième instances de l’opérateur 14.
Puis, lors d’une cinquième sous-étape 245 de raccordement de l’entrée de l’élément graphique décomposeur, le deuxième utilisateur raccorde un élément graphique de flux 102 provenant d’une source de données (non représentée), par exemple un capteur, à l’entrée 86 de l’élément graphique décomposeur 82. La donnée sortante produite par la source de données est de ce fait considérée, par l’élément graphique décomposeur 82, comme une donnée complexe.
L’environnement visuel 50 présente alors, lors d’une sixième sous-étape 246 de présentation des sorties de l’élément graphique décomposeur, des représentations de données basiques, constituées ici par les éléments graphiques de flux 105, 106, 107, 108, 109 représentant les données basiques résultant de la décomposition de la donnée sortante produite par la source de données. Ces données basiques consistent typiquement en cinq déplacements de dent d’odomètre.
Les éléments graphiques de flux 105, 106, 107, 108, 109 sont alors raccordés à l’entrée 59 de l’élément graphique 56 lors d’une septième sous-étape 247.
Enfin, lors d’une huitième sous-étape 248 de raccordement des entrées et des sorties restantes, le deuxième utilisateur raccorde les entrées 58, 60, 61, 62, 63, 64, 65 restantes et les sorties 70, 71, 72, 73 restantes des éléments graphiques 52, 53, 54, 55, 56, 57 au moyen d’éléments graphiques de flux 100, 101, 103, 110, 111, 112, 113, 114, 115, 116, 118. En particulier, dans l’exemple représenté, le deuxième utilisateur raccorde :
l’entrée 58 de l’élément graphique fonctionnel 56, au moyen de l’élément graphique de flux 101, à une source de données (non représentée), par exemple une source de données de configuration, l’entrée 60 de l’élément graphique fonctionnel 57, au moyen de l’élément graphique de flux 103, à une source de données (non représentée), par exemple la sortie d’un élément graphique fonctionnel (non représenté) représentant un opérateur produisant des données de type vitesse linéaire ;
la sortie 72 de l’élément graphique fonctionnel 57 aux entrées 63 des éléments graphiques fonctionnels 52, 53 via les éléments graphiques de flux 112, 113, la sortie 70 de l’élément graphique fonctionnel 56 à l’entrée 60 de l’élément graphique fonctionnel 54 au moyen de l’élément graphique de flux 111, la sortie 71 de l’élément graphique fonctionnel 56 à l’entrée 61 de l’élément graphique fonctionnel 55, au moyen de l’élément graphique de flux 110, l’entrée 62 de chacun des éléments graphiques fonctionnels 52, 53, au moyen respectivement des éléments graphiques de flux 100, 104, à une source de données respective (non représentée), par exemple une source de données de configuration, la sortie 72 de l’élément graphique fonctionnel 54 à l’entrée 65 de chacun des éléments graphiques fonctionnels 52, 53, au moyen respectivement des éléments graphiques de flux respectif 115, 116, et à un consommateur de données (non représenté), par exemple un opérateur fonctionnel de localisation de train, au moyen de l’élément graphique de flux 118, et la sortie 73 de l’élément graphique fonctionnel 55, au moyen des éléments graphiques de flux 114, 117 aux entrées 64 respectivement de l’élément graphique fonctionnel 53 et de l’élément graphique fonctionnel 52,
Avantageusement, cette étape de construction 240 est mise en oeuvre en application des normes CENELEC EN 50128 et CEI 62279, c’est-à-dire en respectant les phases et les livrables définies par ces normes pour le développement applicatif.
Finalement, suite à l’étape de construction 240, le deuxième utilisateur lance le module d’implantation 24, lequel module 24 implante, lors d’une cinquième étape 250 d’implantation, le programme de signalisation ferroviaire 11 à partir de la représentation visuelle 22.
Le programme de signalisation ferroviaire 11 est pour finir enregistré sur le support de stockage 26 lors d’une étape finale 260 d’enregistrement.
Grâce à l’invention décrite ci-dessus, les coûts et le temps d’élaboration de programmes de signalisation ferroviaire sont considérablement réduits. En effet, le système et le procédé d’élaboration 10, 200 permettent de réutiliser aisément les opérateurs informatiques 14, 15, 16, 17 programmés en langage textuel ; il est ainsi possible de reprendre facilement des portions de code d’un programme de signalisation ferroviaire pour produire un autre programme de signalisation ferroviaire. En outre, le système et le procédé d’élaboration 10, 200 permettent aux équipes logiciel et aux équipes système de travailler en parallèle, ce qui réduit de manière évidente la durée totale de développement du programme.
L’invention simplifie également l’implémentation du programme de signalisation ferroviaire 11, et permet de détecter et de résoudre facilement les erreurs dans les spécifications du programme.
Enfin, l’invention permet d’élaborer un programme de signalisation ferroviaire avec un haut niveau de sécurité, puisque l’élaboration est effectuée en application des normes CENELEC 50128 et IEC 62279.
Claims (15)
- REVENDICATIONS1. - Système (10) d’élaboration d’un programme de signalisation ferroviaire (11), comprenant un module de programmation en langage textuel (12) pour la programmation, par au moins un utilisateur, d’au moins un opérateur informatique (14, 15, 16, 17), et une mémoire (18) pour le stockage du ou de chaque opérateur informatique (14, 15, 16, 17) programmé au moyen du module de programmation (12), caractérisé en ce que le système d’élaboration (10) comprend également un environnement visuel (50) pour la présentation, sous forme d’élément graphique fonctionnel (52, 53, 54, 55, 56, 57), d’au moins un opérateur informatique (14, 15, 16, 17) stocké dans la mémoire (18), l’environnement visuel (50) étant adapté pour permettre la construction, par au moins un utilisateur, d’une représentation visuelle (22) du programme de signalisation ferroviaire (11) à partir du ou de chaque élément graphique fonctionnel (52, 53, 54, 55, 56, 57), le système de production (10) comprenant encore un module d’implantation (24) apte à implanter le programme de signalisation ferroviaire (11) en fonction de la représentation visuelle (22).
- 2, - Système d’élaboration (10) selon la revendication 1, dans lequel l’environnement visuel (50) permet la duplication du ou de chaque élément graphique fonctionnel (52, 53, 54, 55, 56, 57), de manière à former un élément graphique dupliqué (53, 57).
- 3. - Système d’élaboration (10) selon la revendication 1 ou 2, dans lequel le ou chaque opérateur informatique (14, 15, 16, 17) est configuré pour traiter au moins un type prédéfini de données entrantes et produire au moins un type prédéterminé de données sortantes, le ou chaque élément graphique fonctionnel (52, 53, 54, 55, 56, 57) présentant, pour le ou chaque type prédéfini, une entrée (58, 59, 60, 61, 62, 63, 64, 66) respective pour l’alimentation de l’opérateur informatique (14, 15, 16, 17) avec au moins une donnée entrante dudit type prédéfini, et, pour le ou chaque type prédéterminé, une sortie (70, 72, 74, 76, 78) respective pour la fourniture, par l’opérateur informatique (14, 15, 16, 17), d’au moins une donnée sortante dudit type prédéterminé, et l’environnement visuel (50) comprend au moins un élément graphique de flux (100, ..., 121) pour raccorder les entrées (58, 59, 60, 61,62, 63, 64, 66) et les sorties (70, 72, 74, 76, 78) du ou de chaque élément graphique fonctionnel (52, 53, 54, 55, 56, 57) de manière à construire la représentation visuelle (22).
- 4, - Système d’élaboration (10) selon la revendication 3, dans lequel l’environnement visuel (50) est adapté pour empêcher le raccordement d’entrées (59, 60, 61, 62, 63, 64, 65, 84, 85, 86) correspondant à un type prédéfini à des sorties (70, 71,72,73, 74, 90, 105, 106, 107, 108, 109) correspondant à un type prédéterminé différent dudit type prédéfini et qui n’englobe ni ne constitue un sous-type dudit type prédéfini.
- 5. - Système d’élaboration (10) selon la revendication 3 ou 4, dans lequel chaque opérateur (14, 15, 16, 17) présente, pour chaque type de données entrantes et sortantes qu’il est configuré pour traiter, respectivement pour produire, une cardinalité dudit type de données définissant le nombre de données dudit type que l’opérateur (14, 15, 16, 17) est adapté pour traiter, respectivement pour produire, à chaque instance dudit opérateur (14, 15, 16, 17).
- 6. - Système d’élaboration (10) selon la revendication 5, dans lequel au moins un opérateur (14, 15, 16, 17) présente une cardinalité fixe pour au moins un type de données entrantes ou sortantes qu’il est configuré pour traiter, respectivement pour produire, et l’environnement visuel (50) est adapté pour empêcher le raccordement, à la ou chaque entrées (59, 60, 61, 62, 63, 64, 65, 84, 85, 86) et/ou à la ou chaque sortie (70, 71,72, 73,74, 90, 105, 106, 107, 108, 109) à laquelle est associée une cardinalité fixe, d’un nombre d’éléments graphiques de flux (100, ..., 121) différent de cette cardinalité.
- 7. - Système d’élaboration (10) selon la revendication 5 ou 6, dans lequel au moins un opérateur (14, 15, 16, 17) présente une cardinalité variable pour au moins un type de données entrantes ou sortantes qu’il est configuré pour traiter, respectivement pour produire.
- 8. - Système d’élaboration (10) selon l’une quelconque des revendications 3 à 7, dans lequel l’environnement visuel (50) comprend au moins un élément graphique agrégateur (80) pour l’agrégation de plusieurs données de types basiques en au moins une donnée de type complexe, l’environnement visuel (50) comprenant également au moins un élément graphique de flux (119, 120, 121) pour le raccordement d’au moins une entrée (84, 85) et/ou d’une sortie (90) de l’élément graphique agrégateur (80) à au moins une sortie (74), respectivement à au moins une entrée d’un élément graphique fonctionnel (52, 53).
- 9. - Système d’élaboration (10) selon la revendication 8, dans lequel l’élément graphique agrégateur (80) présente, pour chaque type basique, une cardinalité dudit type basique définissant le nombre de données dudit type basique que l’élément graphique agrégateur (80) est adapté pour agréger au sein de la donnée de type complexe, la cardinalité associée à au moins un desdits types basiques étant variable.
- 10. - Système d’élaboration (10) selon l’une quelconque des revendications 3 à 9, dans lequel l’environnement visuel (50) comprend au moins un élément graphique décomposeur (82) pour la décomposition d’au moins une donnée de type complexe en plusieurs données de types basiques, l’environnement visuel (50) comprenant également19 au moins un élément graphique de flux (102, 105, 106, 107, 108, 109) pour le raccordement d’une entrée (86) et/ou d’au moins une sortie (91, 92, 93, 94, 95) de l’élément graphique décomposeur (82) à au moins une sortie, respectivement à au moins une entrée (59), d’un élément graphique fonctionnel (56).
- 11, - Procédé (200) d’élaboration d’un programme de signalisation ferroviaire (11) au moyen d’un système de production (10) selon l’une quelconque des revendications précédentes, caractérisé en ce qu’il comprend les étapes suivantes :- programmation (210), par un premier utilisateur, au moyen du module de programmation (12), d’une pluralité d’opérateurs informatiques (14, 15, 16, 17),- stockage (220) dans la mémoire (18) de chaque opérateur informatique (14, 15, 16, 17) produit,- présentation (230) dans l’environnement visuel (50) de chaque opérateur informatique (14, 15, 16, 17) stocké, sous forme d’un élément graphique fonctionnel (52, 53, 54, 55, 56, 57),- construction (240) d’une représentation visuelle (22) du programme de signalisation ferroviaire (11), par un deuxième utilisateur, dans l’environnement visuel (50), à partir des éléments graphiques fonctionnels (52, 53, 54, 55, 56, 57), et- implantation (250) du programme de signalisation ferroviaire (11) à partir de la représentation visuelle (22), par le module d’implantation (24).
- 12, - Procédé d’élaboration (200) selon la revendication 11, dans lequel le ou chaque opérateur informatique (14, 15, 16, 17) est configuré pour traiter au moins un type prédéfini de données entrantes et produire au moins un type prédéterminé de données sortantes, et le ou chaque élément graphique fonctionnel (52, 53, 54, 55, 56) présente, pour le ou chaque type prédéfini, une entrée (58, 59, 60, 61, 62, 63, 64, 66) respective pour l’alimentation de l’opérateur informatique (14, 15, 16, 17) avec au moins une donnée entrante dudit type prédéfini, et, pour le ou chaque type prédéterminé, une sortie (70, 72, 74, 76, 78) respective pour la fourniture, par l’opérateur informatique (14, 15, 16, 17), d’au moins une donnée sortante dudit type prédéfini.
- 13, - Procédé d’élaboration (200) selon la revendication 11 ou 12, dans lequel l’étape de construction de la représentation visuelle (240) comprend une sous-étape (243) de raccordement, par le deuxième utilisateur, dans l’environnement visuel (50), des sorties (74) de plusieurs éléments graphiques fonctionnels de bas niveau (52, 53) aux entrées (84, 85) d’un élément graphique agrégateur (80), et la présentation (244), par l’environnement visuel (50), d’une représentation d’un flux de données de type complexe (121) représentant un flux de données de type complexe résultant de l’agrégation de données sortantes produites par le ou les opérateurs informatiques (14) représentés par lesdits éléments graphiques fonctionnels de bas niveau (52, 53).
- 14, - Procédé d’élaboration (200) selon l’une quelconque des revendications 11 à13, dans lequel l’étape de construction de la représentation visuelle (240) comprend une5 sous-étape (246) de raccordement, par le deuxième utilisateur, dans l’environnement visuel (50), d’une sortie (102) d’un élément graphique fonctionnel de haut niveau à une entrée (86) d’un élément graphique décomposeur (82), et la présentation, par l’environnement visuel (50), de représentations de flux de données de types basiques (105, 106, 107, 108, 109) représentant des flux de données de types basiques résultant10 de la décomposition d’une donnée sortante produite par l’opérateur informatique représenté par l’élément graphique fonctionnel de haut niveau.
- 15. - Procédé d’élaboration (200) selon l’une quelconque des revendications 11 à14, dans lequel l’étape de programmation (210) est mise en œuvre en application des normes CENELEC EN 50128 et CEI 62279.
Priority Applications (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1850893A FR3077664A1 (fr) | 2018-02-02 | 2018-02-02 | Systeme d'elaboration d'un programme de signalisation ferroviaire et procede d'elaboration associe |
| AU2019200597A AU2019200597B2 (en) | 2018-02-02 | 2019-01-30 | Development system for developing a railway signalization program and associated development method |
| SA119400419A SA119400419B1 (ar) | 2018-02-02 | 2019-01-31 | نظام تطوير لتطوير برنامج لإرسال الإشارات خاص بالسكك الحديدية وطريقة للتطوير مرتبطة به |
| CA3032387A CA3032387A1 (fr) | 2018-02-02 | 2019-01-31 | Systeme d'elaboration d'un programme de signalisation ferroviaire et procede d'elaboration associe |
| SG10201900944VA SG10201900944VA (en) | 2018-02-02 | 2019-02-01 | Development system for developing a railway signalization program and associated development method |
| BR102019002156A BR102019002156A8 (pt) | 2018-02-02 | 2019-02-01 | Sistema de desenvolvimento e método de desenvolvimento |
| US16/265,329 US11106436B2 (en) | 2018-02-02 | 2019-02-01 | Development system for developing a railway signalization program and associated development method |
| CN201910108624.8A CN110134389B (zh) | 2018-02-02 | 2019-02-02 | 开发铁路信号化程序的开发系统及相关开发方法 |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1850893 | 2018-02-02 | ||
| FR1850893A FR3077664A1 (fr) | 2018-02-02 | 2018-02-02 | Systeme d'elaboration d'un programme de signalisation ferroviaire et procede d'elaboration associe |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3077664A1 true FR3077664A1 (fr) | 2019-08-09 |
Family
ID=63209465
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1850893A Pending FR3077664A1 (fr) | 2018-02-02 | 2018-02-02 | Systeme d'elaboration d'un programme de signalisation ferroviaire et procede d'elaboration associe |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US11106436B2 (fr) |
| CN (1) | CN110134389B (fr) |
| AU (1) | AU2019200597B2 (fr) |
| BR (1) | BR102019002156A8 (fr) |
| CA (1) | CA3032387A1 (fr) |
| FR (1) | FR3077664A1 (fr) |
| SA (1) | SA119400419B1 (fr) |
| SG (1) | SG10201900944VA (fr) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5261043A (en) * | 1991-03-12 | 1993-11-09 | Hewlett-Packard Company | Input and output data constraints on iconic devices in an iconic programming system |
| US5999729A (en) * | 1997-03-06 | 1999-12-07 | Continuum Software, Inc. | System and method for developing computer programs for execution on parallel processing systems |
| US20020095653A1 (en) * | 1999-03-30 | 2002-07-18 | Shawn Parr | Visual architecture software language |
| US20120084695A1 (en) * | 2010-09-30 | 2012-04-05 | The Mathworks, Inc. | Identification of semantically relevant concepts in a graphical model |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006051355A1 (fr) | 2004-11-15 | 2006-05-18 | Abb As | Systeme de commande, procede de fonctionnement d'un systeme de commande, signal de donnees informatiques et interface utilisateur graphique pour vehicules sur rails |
| US7681176B2 (en) * | 2005-03-04 | 2010-03-16 | Microsoft Corporation | Generating a graphical designer application for developing graphical models |
| EP2085879A1 (fr) | 2008-02-04 | 2009-08-05 | Siemens Aktiengesellschaft | Procédé de fonctionnement d'un appareil de programmation, programme informatique destiné à l'implantation du procédé et appareil de programmation fonctionnant selon le procédé ou appareils de programmation dotés d'un tel programme informatique |
| CN103677763A (zh) * | 2012-08-30 | 2014-03-26 | 中国科学院软件研究所 | 一种图形化编程的源文件存储及解析方法 |
| US9443331B2 (en) * | 2013-06-06 | 2016-09-13 | Microsoft Technology Licensing, Llc | Input object for routing input for visual elements |
| US10496619B2 (en) * | 2014-09-02 | 2019-12-03 | Ab Initio Technology Llc | Compiling graph-based program specifications |
| US10338897B2 (en) * | 2017-03-03 | 2019-07-02 | Stratedigm, Inc. | Visual protocol designer |
-
2018
- 2018-02-02 FR FR1850893A patent/FR3077664A1/fr active Pending
-
2019
- 2019-01-30 AU AU2019200597A patent/AU2019200597B2/en active Active
- 2019-01-31 CA CA3032387A patent/CA3032387A1/fr active Pending
- 2019-01-31 SA SA119400419A patent/SA119400419B1/ar unknown
- 2019-02-01 SG SG10201900944VA patent/SG10201900944VA/en unknown
- 2019-02-01 US US16/265,329 patent/US11106436B2/en active Active
- 2019-02-01 BR BR102019002156A patent/BR102019002156A8/pt unknown
- 2019-02-02 CN CN201910108624.8A patent/CN110134389B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5261043A (en) * | 1991-03-12 | 1993-11-09 | Hewlett-Packard Company | Input and output data constraints on iconic devices in an iconic programming system |
| US5999729A (en) * | 1997-03-06 | 1999-12-07 | Continuum Software, Inc. | System and method for developing computer programs for execution on parallel processing systems |
| US20020095653A1 (en) * | 1999-03-30 | 2002-07-18 | Shawn Parr | Visual architecture software language |
| US20120084695A1 (en) * | 2010-09-30 | 2012-04-05 | The Mathworks, Inc. | Identification of semantically relevant concepts in a graphical model |
Non-Patent Citations (1)
| Title |
|---|
| INGALLS D ET AL: "FABRIK A VISUAL PROGRAMMING ENVIRONMENT", PROCEEDINGS OF THE OBJECT ORIENTED PROGRAMMING SYSTEMS LANGUAGES AND APPLICATIONS CONFERENCE. (OOPSLA). SAN DIEGO, SEPT. 25 - 30, 1988. SPECIAL ISSUE OF SIGPLAN NOTICES, VOL. 23, NO. 11, NOV. 1988; [PROCEEDINGS OF THE OBJECT ORIENTED PROGRAMMING SYST, vol. 23, 25 September 1988 (1988-09-25), pages 176 - 190, XP000299827 * |
Also Published As
| Publication number | Publication date |
|---|---|
| AU2019200597A1 (en) | 2019-08-22 |
| CN110134389B (zh) | 2024-08-02 |
| US11106436B2 (en) | 2021-08-31 |
| BR102019002156A2 (pt) | 2019-08-20 |
| AU2019200597B2 (en) | 2024-07-04 |
| BR102019002156A8 (pt) | 2023-05-09 |
| SG10201900944VA (en) | 2019-09-27 |
| CN110134389A (zh) | 2019-08-16 |
| CA3032387A1 (fr) | 2019-08-02 |
| SA119400419B1 (ar) | 2022-07-19 |
| US20190243614A1 (en) | 2019-08-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2569878A1 (fr) | Procede et systeme de visualisation amelioree par l'emploi de la couleur pour un systeme de commande numerique | |
| EP1527387A2 (fr) | Logiciel de generation de code d application informatique et langage de description de logiciel | |
| FR2785066A1 (fr) | Procede et dispositif d'aide a la maintenance d'un systeme complexe, notamment un aeronef | |
| FR2783455A1 (fr) | Systeme de gestion de processus base sur un processeur offrant des possibilites de programmation intuitive | |
| CA2667111A1 (fr) | Outil informatique de gestion de documents numeriques | |
| FR2747209A1 (fr) | Police de lettres creuses a restitution progressive et ses procedes de creation, transmission et restitution | |
| Guessi et al. | Characterizing architecture description languages for software-intensive systems-of-systems | |
| FR2947080A1 (fr) | Procede pour controler la surete de fonctionnement d'un systeme | |
| FR2990547A1 (fr) | Systeme de maintenance centralisee parametrable destine a un aeronef | |
| FR3077664A1 (fr) | Systeme d'elaboration d'un programme de signalisation ferroviaire et procede d'elaboration associe | |
| FR3021769A1 (fr) | Dispositif et procede de generation d'au moins un fichier informatique pour la realisation d'une interface graphique d'un equipement electronique, et produit programme d'ordinateur associe | |
| FR3045822A1 (fr) | Procede permettant d alimenter les donnees de diagnostiques pour generer les tests de controle dans un processus de controle technique | |
| EP3195113B1 (fr) | Procédé de vérification de traçabilité de premières instructions en un langage de programmation procédurale générées à partir de secondes instructions en un langage de modélisation | |
| FR2923925A1 (fr) | Procede d'evaluation de la surete de fonctionnement d'un systeme | |
| WO2017108924A1 (fr) | Procédé de détection de problèmes de testabilité d'un module informatique | |
| WO2014001543A1 (fr) | Procédé de traitement de données en sécurité, et calculateur associé | |
| EP4057271B1 (fr) | Procédé de test d'un dispositif électroportatif | |
| FR2825491A1 (fr) | Procede d'implementation d'un pluralite d'interfaces d'objets | |
| CN113420893B (zh) | 维修案例生成方法、装置、电子设备及存储介质 | |
| WO2009083574A1 (fr) | Procede de realisation d'un outil universel perenne de developpement de tests d'equipements et outil de mise en oeuvre | |
| FR3077663A1 (fr) | Procede d'elaboration d'un programme informatique et dispositif d'elaboration correspondant | |
| FR2806498A1 (fr) | Systeme informatique de calcul et procede de calcul mis en oeuvre au moyen d'un tel systeme | |
| EP3792866B1 (fr) | Processeur graphique et procédé associé d'affichage d'un ensemble de pixel(s), plateforme et système avionique associés | |
| Campagna et al. | Leveraging the BPMN standard to govern engineering processes in a collaborative environment | |
| FR3008201A1 (fr) | Systeme de validation d'un systeme de controle-commande |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20190809 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |