DÉVELOPPEMENT LOGICIEL MISE À JOUR DE …eprints2.insa-strasbourg.fr/1264/1/GE5E-2012-RuppLaurent-Mémoire... · de fin d’études en son sein. Je remercie le Docteur Ralf Späth,

Confidentiel Laurent RUPP GE5E page 1

RUPP LAURENT GE5E Promotion 2011/2012

Liebherr-France SAS 2 avenue Joseph Rey

B.P. 90287F-68005 Colmar / Cedex

DÉVELOPPEMENT LOGICIEL, MISE À JOUR DE CAHIER DES

CHARGES AINSI QUE DES PROCÉDURES DE TEST LOGICIEL

POUR PELLES HYDRAULIQUES DE TERRASSEMENT

Référents École :

M. Eddie SMIGIEL

M. François DE BERTRAND

DE BEUVRON

Responsables Entreprise : M. François NIERENBERGER

M. Frédéric KNECHT

Durée :

Du 6 février au 3 Août 2012

Rapport

Confidentiel

PROJET DE FIN D'ÉTUDES


Fiche d'objectifs

Dans le cadre de ma formation d'Ingénieur Génie Électrique, à l’INSA de

Strasbourg, j’ai été amené à effectuer mon stage au sein de la Société LIEBHERR

France sur le site de Colmar, spécialisée dans la conception et la fabrication de pelles

hydrauliques sur chenilles. Cette phase en entreprise constitue l'aboutissement de la

formation qui a pour but d’approfondir et d’appliquer les méthodes et les

connaissances acquises.

J’ai choisi d’intégrer la Société LIEBHERR pour plusieurs raisons :

• Je voulais travailler dans le bureau d’études d’une entreprise à renommée

internationale afin d’être en contact permanent avec des Ingénieurs.

• J'ai voulu découvrir le travail en groupe au sein d'une équipe compétente et

professionnelle afin de pouvoir évoluer.

Mes objectifs personnels :

• Accumuler de l’expérience sur les plans techniques, professionnels et

humains.

• Comprendre l’organisation et la manière de travailler en équipe dans un

bureau d’études où les projets sont réalisés en parallèle avec d'autres

services.

• M’intégrer et être autonome dans les missions qui me seront confiées.


Résumé

Développement de fonctions logicielles en suivant les étapes cycle en V, depuis la

définition du cahier des charges jusqu'aux tests finaux. La phase descendante du cycle en V

correspondant à la définition du projet, la phase montante correspond quant à elle aux

différents tests de vérification. Utilisation du logiciel SCADE : pour définir graphiquement

une fonction et pouvoir la simuler pour en vérifier les différents résultats attendus. Utilisation

d'un banc de test pour valider les fonctions développées en corrélation avec ses différentes

spécifications. Amélioration des temps de calcul en optimisant le code C généré.

Development of software functions by following the steps of the V cycle, since the

definition of the specifications, until the final tests. The downward phase of the cycle V

corresponding to the definition of the project. The rising phase corresponds as the various

tests of check. Use of the software SCADE to define diagrammatically a function and be able

to feign it, to verify the various expected results. Use of a bench of test to validate the

developed functions, in correlation with its various specifications. Improvement of the

calculation time by optimizing the code C generated.


Sommaire

Fiche d'objectifs .................................................................................................................. 2

Résumé ................................................................................................................................ 3

Table des illustrations ......................................................................................................... 6

Remerciements .................................................................................................................... 8

Introduction ......................................................................................................................... 9

1) Le groupe Liebherr : ..................................................................................................... 10

1.1) Historique : ............................................................................................................ 10

1.2) Domaines d'activité du groupe :............................................................................. 11

1.3) Situation du groupe : .............................................................................................. 12

1.4) Liebherr France SAS : ........................................................................................... 13

1.4.1) Présentation : ....................................................................................................... 13

1.4.2) Les produits Liebherr terrassement : .................................................................. 14

1.4.3) Organisation du service : .................................................................................... 15

2) Pelles hydrauliques de terrassement : ........................................................................... 16

2.1) Généralité, vocabulaire : ........................................................................................ 16

2.2) Plateforme PME (Product Management Electronic) : ........................................... 18

2.3) Présentation de l'architecture électronique : .......................................................... 18

3) Logiciel, règles et outils utilisés : ................................................................................. 20

3.1) SCADE : ................................................................................................................ 20

3.2) L'outil de diagnostique SCULI : ............................................................................ 23

3.3) Règles de définition des variables système : ......................................................... 24

3.4) Nom des variables dans les fonctions logicielles : ................................................ 26

3.5) Variables Toolkit : ................................................................................................. 28

3.6) L'outil PMELINK : ................................................................................................ 29

3.7) Architecture du programme : ................................................................................. 30


4) Développement de fonctions logicielles : ..................................................................... 31

4.1) Le cycle en V. ........................................................................................................ 32

4.2) Les étapes du cycle en V : ..................................................................................... 33

4.3) Rédaction des spécifications d'une fonction : ........................................................ 35

4.4) Architecture du programme : ................................................................................. 37

4.5) Descriptions graphique de la fonction : ................................................................. 38

4.6) Codage de la fonction : .......................................................................................... 43

4.7) Tests Modulaires : .................................................................................................. 44

4.8) Tests d'intégration : ................................................................................................ 47

4.9) Test sur pelle : ........................................................................................................ 51

5) Présentation du banc de test : ........................................................................................ 52

6) Fonctions réalisées : ...................................................................................................... 55

Conclusion : ...................................................................................................................... 56


Table des illustrations

Figure 1 : Site de production Liebherr .............................................................................. 10

Figure 2 : Domaine du bâtiment et des travaux publics .................................................... 11

Figure 3 : Autres secteurs d'activités ................................................................................. 11

Figure 4 : Chiffre d'affaires par groupe produits ............................................................... 12

Figure 5 : Effectifs du groupe par région. ......................................................................... 13

Figure 6 : Site de Liebherr Colmar ................................................................................... 13

Figure 7 : Gamme de produits Liebherr fabriqués à Colmar ............................................ 14

Figure 8 : Constitution d’une pelle hydraulique Liebherr ................................................. 16

Figure 9 : Organes de contrôles et de commandes d'une pelle Advanced ........................ 17

Figure 10 : Plateforme PME. Architecture électronqiue ................................................... 18

Figure 11 : Domaines d'application du logiciel SCADE .................................................. 21

Figure 12 : Exemple d'opérateurs utilisés ......................................................................... 21

Figure 13 : Slot sur le master pour carte Compact Flash .................................................. 22

Figure 14: Interface de SCULI .......................................................................................... 23

Figure 15 : Exemple Variable Toolkit .............................................................................. 28

Figure 16 : L'outil PMELINK ........................................................................................... 29

Figure 17 : Architecture du programme ............................................................................ 30

Figure 18 : Le cycle en V .................................................................................................. 32

Figure 19 : Fonction Commutation Pédale vers Godet ..................................................... 35

Figure 20 : Bouton correspondant. .................................................................................... 36

Figure 21 : Architecture de la fonction ............................................................................. 37

Figure 22 : Fenêtre principale de SCADE ........................................................................ 38

Figure 23 : Description graphique de la fonction .............................................................. 39

Figure 24 : Définition graphique de la fonction PumpManageAutoId ............................. 40

Figure 25 : Définition Graphique de la rampe .................................................................. 41

Figure 26 : Exemple d'un résultat de check incorrect ....................................................... 42

Figure 27 : Résultat du check sans erreurs OK ................................................................. 43

Figure 28 : KCG: Générateur de code C. .......................................................................... 43

Figure 29 : Scénario de tests modulaire ............................................................................ 44

Figure 30 : Chargement du script TCL ............................................................................. 44

Figure 31 : Simulation SCADE ......................................................................................... 45


Figure 32 : Test modulaire qui a échoué ........................................................................... 46

Figure 33 : Résultat final correct pour le test modulaire ................................................... 47

Figure 34 : Principe des tests d'intégration ....................................................................... 48

Figure 35 : Banc de test utilisé .......................................................................................... 48

Figure 36: Scénario de tests d'intégration ......................................................................... 49

Figure 37 : Test d'intégration qui à échoué ....................................................................... 49

Figure 38 : Résultat final correct pour le test d'intégration ............................................... 50

Figure 39 : Exemple de courbe sous SCULI ..................................................................... 51

Figure 40 : Banc de test utilisé .......................................................................................... 52

Figure 41 : Paramètre de la caméra activé. ....................................................................... 53

Figure 42 : Menu de climatisation .................................................................................... 54

Figure 43 : Surveillance des pressions et températures .................................................... 54


Remerciements

Je remercie la Société Liebherr France SAS pour m’avoir permis d’effectuer mon projet

de fin d’études en son sein. Je remercie le Docteur Ralf Späth, directeur du bureau d’études et

Monsieur Frédéric Knecht, responsable du service électrique - électronique pour m’avoir

permis d’évoluer sous leur responsabilité.

Je remercie plus particulièrement :

Monsieur François Nierenberger, mon tuteur, pour sa disponibilité et toute l'aide

nécessaire qu'il a su m'apporter au cours de mon stage, me guidant ainsi dans la réalisation de

ma mission.

Je remercie également Fabrice Gagliardi, Ingénieur Développeur, qui m’a donné des

points clés pour améliorer mon apprentissage, et, ainsi pouvoir avancer sur les points qui me

bloquaient.

Messieurs Fabrice Weibel, Olivier Schneider, Christophe Shill, Hubert Fuhrman, et

Laurent Hubert qui ont su, grâce à leurs compétences techniques, me donner les éléments

pour avancer plus rapidement dans le développement de mes fonctions logicielles à réaliser.

Messieurs Eddie Smigiel et François De Bertrand De Beuvron pour m'avoir apporté un

avis extérieur sur le déroulement de ce projet.

Enfin, je remercie l’ensemble du personnel du groupe Liebherr avec lequel j’ai été amené

à travailler pendant ces six mois pour avoir fait preuve de disponibilité à mon égard.


Introduction

J'ai été accueilli le 6 février 2011 dans l'entreprise Liebherr France SAS, au sein du

bureau d'études service électrique, en charge de l'étude des fonctions logicielles pour pelles

hydrauliques de terrassement nouvelles générations.

Ma mission principale a été de développer ou de mettre à jour ces fonctions logicielles,

en partant d'un cahier des charges et en suivant toutes les étapes du cycle en V qui seront

décrites au cours de mon exposé.

J'ai utilisé le logiciel SCADE qui est un environnement de développement pour fonctions

sécuritaires critiques, qui sera expliqué également.

La dernière phase de ma mission a concerné les différents tests de mes fonctions. Ces

tests ont pour but de vérifier que le résultat attendu est bien ce qui va être reproduit en réalité

sur la pelle, une fois le programme chargé sur celle-ci.

Je vais expliquer dans le détail les architectures "Hardware" et "Software" qui sont

implantées sur une pelle hydraulique Liebherr. En m'appuyant sur des exemples, je vais vous

démontrer les différentes étapes pour développer une fonction logicielle, ainsi que les

différents outils et méthodes que j'ai appliqués.


1) Le groupe Liebherr :

1.1) Historique : L’entreprise familiale Liebherr a été fondée en 1949 par Hans

Liebherr. La grande réussite de la première grue à tour mobile,

économique et facile à monter, a posé les bases du développement de

l’entreprise. Aujourd’hui, Liebherr compte parmi les plus grands

fabricants mondiaux d’engins de construction et s’est aussi fait un

nom dans de nombreux autres domaines comme fournisseur de

produits et de services de haute technologie et axés sur les besoins

des utilisateurs.

L’entreprise s’est développée pour devenir un groupe employant de 32 979 personnes

dans plus de 120 sociétés sur tous les continents.

Pour son organisation, le Groupe mise sur la décentralisation et sur une structure claire

composée d’unités autonomes. Cette approche lui permet d’être proche de ses clients et de

réagir avec souplesse et rapidité aux signaux du marché et à la concurrence mondiale. Les

sociétés de production et de distribution des différents segments de produits sont placées sous

la direction opérationnelle de sociétés holding. Le Groupe est chapeauté par la société

Liebherr-International AG, de Bulle en Suisse, dont tous les propriétaires sont des membres

de la famille Liebherr. Cette entreprise familiale est dirigée conjointement par Isolde Liebherr

et Willi Liebherr, enfants du fondateur de la société.

Figure 1 : Site de production Liebherr


1.2) Domaines d'activité du groupe :

Le développement et la production des produits et composants sont répartis sur les 30

sites présents dans 12 pays à travers le monde.

Il existe, dans le groupe Liebherr, des activités variées regroupées par métiers :

Figure 2 : Domaine du bâtiment et des travaux publics

• Machines de terrassement avec deux divisions : terrassement & mining :

Fabrication de pelles hydrauliques, de bouteurs, de chargeuses sur pneus et chenilles, de dumpers, de poseurs de canalisations, de tracteurs de soudage.

• Fabrication de grues de navires, de grues mobiles portuaires, de pelles à câbles, de grues-containers, de grues pour plateformes de forage pétrolier. • Grues à tour et techniques du béton : Fabrication de grues à tour, de centrales à béton et de bétonnières portées. • Grues mobiles

Si la technologie Liebherr fait partie intégrante de l’univers du bâtiment et des travaux

publics, le groupe propose également des lignes complètes de produits dans de nombreux

autres secteurs.

Figure 3 : Autres secteurs d'activités


• Machines-outils et installations industrielles : Fabrication de chaînes-transfert, de machines-outils et d’équipements aéronautiques.

• Électroménager : Fabrication de réfrigérateurs, de congélateurs, de caves à vin et de glacières. • Aéronautique : Fabrication de systèmes de commande, de trains d’atterrissage et de systèmes de

climatisation. • Le groupe possède également des hôtels en Irlande, en Autriche et en Allemagne.

1.3) Situation du groupe : Le groupe a comme beaucoup été touché par la crise mondiale. Le chiffre d’affaires

n’avait cessé d’augmenter depuis 2003 pour atteindre le chiffre record de 8,4 milliards

d’euros en 2008 soit environ le double des cinq années auparavant. En 2009, le chiffre

d’affaires a diminué de 17 % et atteint 6,96 milliards : un chiffre s’approchant de l’exercice de

2006.

Figure 4 : Chiffre d'affaires par groupe produits


Figure 5 : Effectifs du groupe par région.

Malgré la crise en 2008, le groupe Liebherr a globalement maintenu son effectif.

1.4) Liebherr France SAS :

1.4.1) Présentation :

La société Liebherr-France SAS produit à Colmar une gamme très diversifiée de pelles

hydrauliques de poids de service compris entre 20 et 100 tonnes.

Liebherr-France SAS fait partie du groupe Liebherr dont la holding Liebherr International

est située à Bulle (Suisse). L’entreprise a été créée en 1961 dans la zone industrielle de

Colmar sur un terrain de 32 hectares.

Figure 6 : Site de Liebherr Colmar


Liebherr France Colmar gère également 4 agences commerciales :

• Agence de Colmar

• Agence de Paris (Fontenay-Trésigny)

• Agence de Marseille (Vitrolles)

• Agence du Sud-ouest (Gradignan)

1.4.2) Les produits Liebherr terrassement :

Liebherr Colmar construit sur mesure des pelles hydrauliques sur chenilles, dans la

gamme des machines et équipements les plus grands du monde. La gamme comprend les

machines de poids en ordre de marche de 14 t à 804 t avec des puissances moteur de 76 kW à

2984 kW. Ainsi, chaque pelle sur chenilles est parfaitement adaptée aux exigences imposées

par l'application pratique.

Tous les équipements de travail, qu'il s'agisse du godet rétro, du godet chouleur à trappes,

ou de l'équipement de démolition ou de manutention, sont développés et fabriqués par

Liebherr.

Figure 7 : Gamme de produits Liebherr fabriqués à Colmar


1.4.3) Organisation du service :

J'ai effectué mon projet de fin d'études au sein du service électrique du bureau

d'études. Ce service, dirigé par M. Frédéric Knecht, développe l'ensemble du système

électrique embarqué sur une pelle hydraulique Liebherr.

Le service est divisé en deux grandes parties :

• Les Ingénieurs "Hardware" : développent et conçoivent la partie électrique de

la plateforme PME. Cela va du faisceau de câblage à l'implantation physique des

éléments sur la pelle.

• Les Ingénieurs "Software" : conçoivent et développent les fonctions logicielles

applicatifs nécessaires au fonctionnement de la pelle.

Le Bureau d'Études réalise ses travaux avec des moyens modernes de conception, de

calcul et de simulation, pour les futures pelles hydrauliques sur chenilles.

Le logiciel SCADE est utilisé par les Ingénieurs développant les fonctions logicielles

embarquées.

Ce travail se fait notamment sur la base de cahiers de charges prenant en compte les

aspects marketing, technologiques, financiers et réglementaires qui sont élaborés avec

l'ensemble des services concernés de l'usine et du groupe.

L'ensemble du personnel de ces départements a obligatoirement un très haut niveau de

qualification étant donné qu'il travaille souvent avec les outils de dernière génération.


2) Pelles hydrauliques de terrassement :

2.1) Généralité, vocabulaire :

Bien que Liebherr conçoive des pelles hydrauliques spécifiques à certaines demandes

clients, que ce soit les pelles spéciales ou les pelles de séries ; elles se décomposent en cinq

éléments mécaniques principaux.

La tourelle (ou plateforme) est liée au châssis par une liaison pivot motorisée. Par des

liaisons pivot, la flèche est liée à la tourelle, le balancier à la flèche et l’outil terminal (godet,

grappin, marteau hydraulique, etc.) au balancier. Les mouvements de ces derniers éléments

sont actionnés hydrauliquement par des vérins.

Figure 8 : Constitution d’une pelle hydraulique Liebherr


Figure 9 : Organes de contrôles et de commandes d'une pelle Advanced


La majorité des commandes hydrauliques des pelles classiques (ancienne génération) est

remplacée par une commandes électriques des pompes, sur les pelles "Advanced" nouvelle

génération, dont le pilotage est devenu plus complexe. Ceci se caractérise par l’augmentation

du nombre de capteurs sur la pelle : entre 20 et 30 contre 7 sur les pelles classiques. Une

architecture électronique appelée Plateforme PME est utilisée pour faire fonctionner la pelle.

2.2) Plateforme PME (Product Management Electronic) :

Une pelle hydraulique de terrassement est constituée d’une interface homme machine

permettant au conducteur de commander les différents outils et mouvements de la pelle. Ses

fonctions sont gérées par un système informatique embarqué sur la pelle : constitué d'un

Master (unité centrale) et de modules d’entrées et sorties qui communiquent en bus CAN.

Cette plateforme s'appelle : Plateforme PME.

C'est la raison pour laquelle les machines de type "Advanced" nécessitent une

programmation plus complexe.

2.3) Présentation de l'architecture électronique :

Figure 10 : Plateforme PME. Architecture électronqiue


Constitution d’une pelle « Advanced »:

- 1 master, élément de traitement central - 4 modules d’entrée + 1 optionnel - 2 modules de sortie + 1 optionnel - 1 display (supportant l’affichage de la vidéo de la caméra de recul) - 4 claviers type TB09 - 1 clavier type TA21 - 1 module de contrôle de climatisation - 1 module de contrôle moteur

La plateforme PME est prévue pour être utilisée sur différents types de machine : pelles,

chargeuses, grues, bouteurs. Par conception, c’est donc une plateforme largement

paramétrable et modulable. Cette plateforme est prévue d’origine pour intégrer des fonctions

de sécurité de fonctionnements avancés : redondance, autotests, surveillance des composants.

Cette architecture est organisée de manière maître/esclave :

• Le master :

C'est l'unité centrale du système qui va communiquer en mode bus CAN avec des

modules d'entrées/sorties. Il va recevoir les données des modules d'entrées via bus

CAN, calculer la valeur des sorties, puis renvoyer ces valeurs via bus CAN sur les

modules de sorties.

• Modules d'entrées/sorties :

Les capteurs de la pelle sont reliés aux modules d'entrées, les actionneurs de la

pelle sont reliés aux modules de sorties. Communication en mode bus CAN.

• Le Display, écran d'affichage et de contrôle :

C'est un écran tactile qui permet au conducteur de la pelle de surveiller le bon

fonctionnement de sa machine, de vérifier les niveaux et pressions hydrauliques,

etc. Comme cet écran est tactile, il va permettre également au conducteur de

pouvoir configurer certaines options, en appuyant directement sur les boutons de

menu à l'écran.

Le Display va également permettre d'afficher à l'écran la vidéo de la caméra de

recul. Il communique avec le master en Ethernet.


• Clavier de contrôle :

5 claviers de contrôle sont à disposition du conducteur. En fonction des

différentes options de la pelle, ils vont permettre d'activer ou de désactiver

certaines fonctions et paramètres. Ils communiquent avec le master en Ethernet.

• Communication :

Un PC peut être connecté via un port Ethernet pour communiquer avec le master.

A l'aide de l'outil de diagnostique SCULI, il est possible de visualiser et de

changer les variables d'entrées et sorties du système. J'expliquerai succinctement

son fonctionnement dans la suite de mon rapport.

3) Logiciel, règles et outils utilisés :

3.1) SCADE :

Que signifie SCADE ?

Safety Critical Application Development Environnement.

SCADE est un logiciel de développement de fonctions critiques créé par l’entreprise

Esterel Technologie. Ce logiciel a été conçu pour répondre à la demande d’Airbus dans le

cadre du programme A380. SCADE permet de faciliter la communication entre les équipes

travaillant sur un même projet et de gérer l’ensemble de la conception d’un programme sur

tout son cycle de développement.

SCADE créator permet de réaliser une programmation graphique des fonctions. Chaque

fonction est représentée sous la forme d’un bloc contenant à gauche les entrées et à droite les

sorties. A l’intérieur de chaque bloc, on trouve la programmation. A l’aide d’éléments de base

tels que des opérateurs mathématiques, des comparateurs, des opérateurs logiques et d’autres

blocs plus élaborés, il est possible de programmer une fonction. SCADE créator est utilisé

pour définir la fonction au plus précis via ce langage graphique.


Figure 11 : Domaines d'application du logiciel SCADE

Figure 12 : Exemple d'opérateurs utilisés


A l'aide de ces différents opérateurs et bibliothèques d'outils intégrés à SCADE il est

donc possible de créer une fonction logicielle.

L'avantage d'utiliser ce logiciel est que l'on définit graphiquement la fonction à créer, il

n'y a pas de ligne code à taper (C, C++) car c'est SCADE lui-même qui va générer le code C.

Il est possible de pouvoir simuler la fonction créée directement sous SCADE et de pouvoir

créer des scénarios pour vérifier son bon fonctionnement.

Le logiciel permet donc en compilant de créer les fichiers "fichier.c", en code C. Ces

fichiers seront transformés en code compréhensible par le master. Une fois ce code chargé

dans le master par l'intermédiaire de carte type "Compact Flash" on pourra vérifier que la

fonction logicielle créée fait ce que l'on attend d'elle, en corrélation avec le cahier des charges.

Figure 13 : Slot sur le master pour carte Compact Flash


3.2) L'outil de diagnostique SCULI :

SCULI (Service Client Universal LIebherr) est un logiciel permettant d’obtenir un certain

nombre d’information en temps réel sur l’état de la machine et de modifier sa configuration.

SCULI communique avec le master PME via un câble Ethernet ou par port RS232. Selon

le droit d’accès de l’utilisateur on peut avoir accès en lecture ou en écriture aux informations.

• Variables : donne les valeurs des variables du système en temps réel.

• Analyseur : renvoie tous les messages sauvegardés sur le master.

• Lift : donne accès aux fichiers stockés sur les cartes CF1 et CF2.

• Modules : renvoie tous les modules définis avec leurs types et les lignes CAN.

Figure 14: Interface de SCULI


3.3) Règles de définition des variables système :

Dans toutes les fonctions SCADE créées, il existe des règles de définition pour les noms

des variables systèmes. Ces règles ont pour but d'avoir une standardisation dans toutes les

usines LIEBHERR qui travaillent avec SCADE.

Grâce à ces règles on va pouvoir retrouver plus facilement le nom des variables sous

SCULI pour les visualiser et éventuellement les modifier.

Des règles définissent l’attribution des noms de variables :

• Le nom est en anglais,

• En un seul bloc (sans espace),

• La première lettre de chaque mot est en majuscule,

• Le nombre de caractères est limité à 24,

• Ne sont autorisés que les caractères numériques et alphabétiques (pas de caractères

spéciaux tels que plus ou moins),

• Exception : les caractères underscore ou moins peuvent être utilisés pour des noms de

caractéristiques électriques (Ex.: „IRSensB55_1_2“),

• Les variables sont citées en italiques et entre guillemets dans les Requirements (Ex :

„IRBtEnablingDownS55_1“),

• Les unités des variables sont définies dans les Requirements et précisées dans les

commentaires SCADE,

• Les caractères grecs doivent être exprimés en anglais et en toutes lettres (a s’écrit

Alpha,p s’écrit Pi).

• Les entrées ne contiennent pas le nom de la fonction (Ex. : „IXSensJsRB19R”,

„IRBtEnablingDownS55_1”)

• Les sorties contiennent le nom de la fonction (Ex. : „QRBuzzerH10”,

QRRotatingSpeedB53”)


Un nom de variable se décompose comme suit : Type de donnée | Format de donnée | Nom du signal | Nom de la caractéristique électrique

• Type de donnée :

Il s’agit de la première lettre, en majuscule :

• Format de donnée :

Il s’agit de la seconde lettre en majuscule :

Format de la donnée Seconde lettre majuscule Booléen X Entier D Réel R

• Nom de donnée :

Le nom de donnée se trouve en troisième position, il doit comprendre au maximal 16

caractères. L’utilisation d’abréviations est souvent utile pour construire le nom du signal.

(Ex. :„IRSensPdlLForwardB170“, Sens = sensor, Pdl = pedal, L = left)

• Nom de caractéristique électrique

En dernière position se trouve le nom de la caractéristique électrique, ce nom comprend 6

caractères au maximum.

Ex. : „IRSensPdlLForwardB170“, B170 est le nom du capteur utilisé

Type de donnée Préfixe Entrée d’un module externe ou d’un opérateur SCADE I Sortie d’un module externe ou d’un opérateur SCADE Q Display (Screen) S Paramètre C Variable mémoire M


Remarques :

• Dans le cas d’un symbole affiché sur le display, le nom sera précédé de l’abréviation

Sym (pour Symbol).

• S’il s’agit d’une variable mémoire, le nom de variables définies dans le Toplevel du

projet SCADE sera précédé de _In ou _Out selon l’utilisation de la variable

respectivement comme entrée ou sortie.

3.4) Nom des variables dans les fonctions logicielles :

Ces noms de variables sont utilisés dans les opérateurs des fonctions SCADE. Les règles

d’attributions des noms sont les mêmes que pour les variables systèmes au détail près que l’on

peut utiliser jusqu’à 32 caractères.

Un nom de variable se décompose comme suit :

Type de donnée | Format de donnée | Nom de la fonction | Nom du signal | “Retain” | Nom du signal

| “Sym” | Nom du signal

• Type de donnée :

Type de donnée Préfixe Entrée d’un module externe ou d’un opérateur SCADE I Sortie d’un module externe ou d’un opérateur SCADE Q Display (Screen) S Probe “espion” L Paramètre C Variable mémoire M Constante K


• Format de donnée :

Data format Second capital letter Booléen X Entier D Réel R

• Nom de la fonction :

En troisième position se trouve le nom de la fonction écrit sous la forme d’une abréviation.

Ex. : „IDTravAlSensPdlRBackward“, TravAl = travel alarm.

Ces abréviations ou descriptions courtes sont listées avec le numéro de la fonction dans

un document Excel accessible par toutes les usines du groupe. Un numéro correspond à une et

une seule fonction.

• Nom du signal :

En dernière position se trouve le nom du signal. S’il s’agit d’un symbole affiché sur le

display, le nom sera précédé de l’abréviation Sym (pour Symbol). S’il s’agit d’une variable

mémoire, le nom sera précédé de l’abréviation Retain (pour RetainValue) pour une utilisation

en sortie et d’Init pour une utilisation comme entrée.

Exemples :

• Input: „IDTravAlSensPdlLBackward”. • Output: „QXQChangeBuzzer”. • Display: „SXQChangeSymEnabled”. • Probes: „LXQChangeBuzzer”.

Il est donc primordial de bien utiliser ces règles pour définir les variables. Un

développeur qui découvre une fonction qu'il n’a pas créé, pour la première fois, ne sera pas

déstabilisé si ces règles sont respectées. Je dois signaler qu'il ma fallu un certain temps

d'adaptation pour réussir moi-même à bien définir les noms de mes variables logicielles. Car

la première fois que l'on découvre ces règles on est un peu perdu.


3.5) Variables Toolkit : Quand on parle de toutes les variables du projet il faut aussi leur donner un type, une

adresse, l'autorisation d'accès en écriture et/ou lecture. Le fichier "VariableToolkit" est une Macro en Excel capable de générer chacune de ces informations.

Pour chaque variable on va avoir:

• L’adresse physique dans le master. • Le type de variables : si c’est une entrée, une sortie, une variable de mémoire

ou une commande. • La valeur de base. La valeur avec laquelle la variable a été initialisée. • Les droits d'accès à la variable. • Le groupe ou la variable apparait pour l’outil diagnostique SCULI.

3 fichiers systèmes vont être générés par cette macro :

• Projet.asc : utilisé dans le module PMElink pour effectuer les connexions Software Hardware. Comprend les noms et adresses des variables.

• Projet.xml : utilisé dans la carte principale du master. Comprend les données du

fichier projet.asc ainsi que les valeurs de base, minimale, maximale et

les configurations des modules.

• Database.xml : utilisé dans la carte principale du master. Comprend les valeurs

des paramètres de fonctionnement de la pelle.

Figure 15 : Exemple Variable Toolkit


3.6) L'outil PMELINK :

PMElink est un module complémentaire de SCADE réalisé spécialement pour Liebherr.

Il permet de connecter les variables logicielles de l’architecture SCADE aux variables

physiques et mémoires du système de contrôle. Pour le principe, il s’agit d’associer

manuellement les variables du projet SCADE aux variables définies dans le projet.asc

générées par la macro VariableToolkit.

Figure 16 : L'outil PMELINK


Le PMELINK va nous être très utile lors, de l'intégration des nouvelles entrée et sorties

logicielles créées, dans le projet d'architecture complet de la pelle.

3.7) Architecture du programme :

Ici on peut voir l'architecture complète d'un programme. Elle comprend plusieurs niveaux

de sécurité.

• Niveau de sécurité des fonctions :

Lors de l’intégration des fonctions logicielles dans le projet complet, il faudra

prendre en compte le niveau de sécurité des fonctions, il comporte 3 niveaux et se

nommé SIL.

Niveau SIL0

Endroit où se trouve la

fonction dans l’architecture.

Niveau SIL1

Figure 17 : Architecture du programme


SIL : Safety Integrity Level

• SIL0: pas de mesure d’intégrité pour les fonctions.

• SIL1: niveau d’intégrité 1 pour les fonctions.

• SIL2: niveau d’intégrité 2 pour les fonctions.

Une fonction de sécurité peut être requise pour prévenir un risque pour le personnel qui

se trouve autour de la machine.

L'étude de ces niveaux de sécurité est faite par le service concerné, et nous devons nous y

conforter lors de la création de la fonction sous SCADE, pour placer la fonction au bon

endroit dans l'architecture du programme.

Nous verrons également que ces niveaux de sécurité SIL ont une importance capitale

dans le cycle en V.

4) Développement de fonctions logicielles :

Dans ce chapitre, je vais expliquer dans les détails la procédure et les différentes

étapes que j'ai appliquées pour développer une fonction logicielle.

Nous verrons pas à pas avec un exemple, comment s'utilisent les différents outils cités

plus haut. Je présenterai aussi les différents tests appliqués sur chaque fonction logicielle

développée pour valider son bon fonctionnement.


4.1) Le cycle en V.

Le cycle en V est un est un modèle conceptuel de développement et de gestion de projet

principalement utilisé pour le développement de programme.

Le cycle en V est donc utilisé, chez Liebherr, pour toutes les fonctions logicielles

développées.

La partie descendante du cycle en V correspond à la définition du projet, la partie

montante aux tests et à l’intégration. Chaque étape de la définition du projet est vérifiée par

l’étape se situant en vis-à-vis dans le V. On vérifie donc en dernier la première partie de la

définition du projet.

Il est donc primordial de respecter scrupuleusement les différentes étapes de

développement pour garantir le bon fonctionnement et le niveau de sécurité d'une fonction.

Figure 18 : Le cycle en V


4.2) Les étapes du cycle en V :

• "Requirement" de haut niveau :

Cette étape contient toutes les exigences d’une fonction. C’est ici qu’on trouvera la

description complète de celle-ci.

• Spécifications du programme :

Dans cette partie on trouvera le fonctionnement de la fonction divisée en différents

«requirements». Les "requirements" sont des exigences de la fonction.

• Architecture du programme :

Elle dépend de la où on veut placer la fonction. Un choix judicieux doit être fait,

surtout si cette fonction dépend des résultats d'une autre.

• Description graphique de la fonction :

C'est dans cette étape que le logiciel SCADE est utilisé. La définition graphique de la

fonction est créée sous SCADE en corrélation avec ses spécifications.

• Codage :

C'est le code généré par le compilateur de SCADE, qui va créer les fichiers "fichier.c"

qui seront ensuite transformés en code compréhensible par le master.

• Test modulaire :

Ces tests sont réalisés sur le PC, sous SCADE avec le simulateur intégré. On va

utiliser des scénarios sous forme de fichiers Excel pour simuler la fonction afin de

vérifier son bon fonctionnement. La fonction est ici testée seule.

• Test d'intégration :

Ces tests sont réalisés sur un banc de test, qui va simuler le fonctionnement de la

plateforme PME au complet. La fonction est ici testée dans le projet complet de la

pelle. On va également utiliser des scénarios Excel à cette étape de validation.


• Test de validation :

Ces tests finaux sont effectués sur une pelle en condition réelle par le service essais.

Toutes les spécifications de la fonction vont être testées pour vérifier, qu’en conditions

réelles, les résultats obtenus sont les mêmes que les tests de simulation et d'intégration.

• Validation du programme :

Quand toutes les phases de tests sont validées, on peut alors "libérer" le programme

avec la ou les nouvelle(s) fonction(s) ajoutée(s). Le programme est alors chargé sur le

master grâce à la carte compacte flash, sur les lignes de production. Et les pelles sont

envoyées chez les clients.

Les niveaux de sécurités SIL interviennent également dans le cycle en V.

• Niveau SIL 0 : toutes les étapes descendantes et ascendantes du cycle en V

peuvent être réalisées par la même personne.


doivent être réalisées par deux personnes différentes qui peuvent être du

même service.


doivent être réalisées par deux personnes différentes qui doivent être de deux

services différents.

Le respect des différentes étapes et niveaux de sécurité du cycle en V est primordial pour

le bon respect des règles en vigueur chez Liebherr. Un manquement à ces règles pourrait

entrainer des risques de blessure voir de mort pour le conducteur de la pelle et le personnel

qui se trouve à proximité.


4.3) Rédaction des spécifications d'une fonction :

Pour illustrer le déroulement du cycle en V, je vais détailler toutes les étapes une à une

avec un exemple.

La première étape de ma mission, pour chaque fonction de la pelle que l'on me donne à

faire, consiste en la rédaction des spécifications ou "requirment" en adéquation avec le cahier

des charges de la fonction.

Une spécification est un document décrivant avec précision la manière dont doit

fonctionner la fonction à développer. Il comprend une description générale en français suivie

d’une description détaillée en anglais. Cette dernière est découpée en différents

"requirements" d’une phrase, clairs, précis et facilement testables.

• Pour illustrer cette étape, je vous propose d'étudier la fonction suivante :

Commutation Pédale AHS11 vers Godet

Figure 19 : Fonction Commutation Pédale vers Godet


Les spécifications pour cette fonction sont nombreuses, mais en voici deux pour donner

un ordre d'idée.

Description : Cette fonction, que j’ai développée, a pour but de transférer les commandes hydrauliques des

pédales vers le joystick en fonction des différentes options sur la pelle.

REQ0740.1 Initial state :

At starting of the machine the output and the safety shut down are forced at low level for 1 s. (IBIT), and then the state machine shall automatically switch into “LED Test” state.

REQ0740.2 The “LED Test” state shall be hold during 3 s. Then the state machine shall

automatically switch into “Deactivated” state.

REQ00740.7 According to the „IXTransCtrlBtTransCtrlAHS“, we have two modes.

Action Output

Buttons „IXTransCtrlBtTransCtrlAHS“ press.

- „QXTransCtrlTransCtrl1AHS“ is True,

- „QXTransCtrlTransCtrl2AHS“ is True,

- „QXTransCtrlLEDTransCtrlAHS” is True.

Buttons „IXTransCtrlBtTransCtrlAHS“ Again press

- „QXTransCtrlTransCtrl1AHS“ is False,

- „QXTransCtrlTransCtrl2AHS“ is False,

- „QXTransCtrlLEDTransCtrlAHS” is False.

Dans la spécification REQ00740.7, on décrit par exemple, ce que doit faire la fonction si

on appuie sur le bouton correspondant sur le clavier qui se situe dans la cabine sur la droite du

conducteur.

Figure 20 : Bouton correspondant.


Ici, si on appuie sur le bouton au clavier, on active la fonction :

• 2 électrovannes sont activées, les débits hydrauliques sont alors commutés et les

commandes sont transférées des pédales vers le joystick.

Si on appuie une seconde fois sur le bouton au clavier, on désactive la fonction :

• 2 électrovannes sont désactivées, les débits hydrauliques sont alors commutés une

seconde fois et les commandes retrouvent leurs configurations d'origine.

4.4) Architecture du programme :

Comme un projet complet (programme) contient un grand nombre de fonctions qui vont

dépendre les unes des autres, il est judicieux de placer les fonctions les plus proches de celles

dont elles dépendent dans l'architecture. Toutefois en fonction des niveaux de sécurité, il n'est

pas toujours possible de les regrouper. Elles pourront, grâce à l'architecture et à des variables

locales, communiquer ensemble.

Figure 21 : Architecture de la fonction


On va pouvoir communiquer entre les fonctions du niveau le plus sécuritaire vers le

moins sécuritaire. L’outil PMElink permet pour cela de connecter localement des sorties d’un

niveau de sécurité supérieur vers un niveau inférieur. Pour bien identifier ces cas, une sortie

de bloc sécuritaire porte le même nom que l’entrée de bloc non sécuritaire correspondante.

Elle est précédée par SIL1voir SIL2.

4.5) Descriptions graphique de la fonction :

C'est à cette étape que l'on commence à définir graphiquement la fonction, sous le

logiciel SCADE, dont voici la fenêtre principale.

Figure 22 : Fenêtre principale de SCADE


• Sur la gauche de la fenêtre on retrouve l'architecture du programme avec l'espace

de travail et les différentes bibliothèques intégrées au projet.

• En haut, les différentes barres de menu.

• Au centre, la zone de définition graphique de la fonction.

• Sur la droite, les différents opérateurs que l'on peut utiliser.

• En bas, la zone de simulation ainsi que les propriétés diverses.

Voici la définition graphique sous SCADE, pour notre fonction.

Figure 23 : Description graphique de la fonction


Pour cette partie, on utilise SCADE Editor. Il s’agit d’un outil graphique permettant de

préciser en détail la fonction développée. Chaque fonction est représentée par un bloc

contenant la programmation avec les entrées à gauche et les sorties à droite. La

programmation est réalisée grâce à des opérateurs mathématiques, des comparateurs, des

portes logiques et d’autres blocs plus élaborés recensés dans des bibliothèques.

Chaque fonction aura une définition graphique qui va correspondre aux différentes

spécifications définies dans la première étape du Cycle en V. C'est la raison pour laquelle il

est important de bien comprendre en écrivant les spécifications, ce que doit faire la fonction.

Si les spécifications ne décrivent pas correctement ce que l'on attend de la fonction à créer

sous SCADE, la définition graphique ne sera pas assez complète pour bien prendre en compte

les différentes attentes.

Exemple Fonction : "PumpManageAutoId" :

Exemple de la définition graphique d'une autre fonction que j'ai développée et qui était

plus complexe que la première.

Figure 24 : Définition graphique de la fonction PumpManageAutoId


• Problème :

Si le mouvement demandé par le conducteur de la pelle est trop brusque alors que le

moteur est au régime ralenti lors du passage du régime ralenti vers le régime demandé, le

moteur a tendance à "s'essouffler". En effet, le débit demandé par les pompes hydrauliques

programmées sous SCADE passant d’une faible valeur à une forte valeur : les pompes

s'ouvrent d'un seul coup et le moteur thermique n'arrive pas à suivre.

• Solution :

J'ai modifié la description graphique de la fonction afin que lorsque le moteur passe du

régime ralenti vers le régime demandé, suite à la demande d'un mouvement du conducteur,

que le débit des pompes s'ouvre cette fois sous forme d'une rampe progressive. Ainsi le

moteur peut prendre son régime demandé sans "s'essouffler".

Figure 25 : Définition Graphique de la rampe

Coefficient de la rampe Valeur finale demandée comparée à

la valeur actuelle de la rampe.

Si la valeur de la rampe est

supérieure à la valeur demandée, alors

on a atteint la valeur demandée et on

ne fait plus la rampe.

Sortie vers l'électrovanne

pour réguler le débit.


Les fonctions que j'ai développées par la suite ont demandé, pour certaines, plus de

réflexion pour décrire graphiquement les spécifications sous SCADE.

Pour vérifier que notre description graphique est correcte et qu'elle ne contient pas

d'erreur, on peut faire un "check", de l'opérateur concerné pour vérifier s'il ne contient pas

d'erreur.

Le "check" va nous aider à trouver les erreurs et à les localiser dans la description

graphique. Les sources d'erreurs sont nombreuses : en voici quelques exemples :

• Type de variables non cohérentes (real, bool, int).

• Initialisation incorrecte.

• Manque un paramètre d'initialisation.

• Une variable est déclarée, mais non utilisée.

Le but final, après correction de toutes ces erreurs, est de finaliser notre description

graphique de la fonction sans erreur et que le résultat du "check" soit sans erreur.

Figure 26 : Exemple d'un résultat de check incorrect


Figure 27 : Résultat du check sans erreurs OK

La description graphique de la fonction est alors terminée et opérationnelle. On peut passer

à l'étape suivante du cycle en V.

4.6) Codage de la fonction :

Pour cette étape du cycle en V, on utilise un générateur de code intégré à SCADE.

Ce générateur de code qui est KCG, va compiler la description graphique de la fonction en

fichier "fichier.C". Ces fichiers pourront alors nous servir pour la simulation de la fonction.

Figure 28 : KCG: Générateur de code C.


4.7) Tests Modulaires :

C'est la première étape de la phase ascendante du cycle en V. Ces tests ont pour but de

valider la description graphique de la fonction. Ces tests sont effectués immédiatement après

la description graphique et simulés sur PC, grâce au simulateur intégré à SCADE. On va

tester chaque fonction d’une manière indépendante.

Pour effectuer la procédure il faut forcer les entrées et observer les valeurs des sorties

attendues. On va faire des « scénarios » sous Excel, pour vérifier que ce que nous avons prévu

en entrées et sorties de la fonction est bien ce que nous attendons.

Grâce à une macro Excel, on génère un script TCL (fichier.sss), que l'on peut ouvrir

ensuite dans le simulateur directement sous SCADE.

Figure 29 : Scénario de tests modulaire

Figure 30 : Chargement du script TCL


On peut alors simuler pas à pas la description graphique de la fonction créée.

Grâce au script, on peut donc simuler les entrées, sorties et transitions et vérifier que le

scénario créé sous Excel, donne le résultat attendu.

On peut voir ici une transition qui est franchie, pour passer de l'état désactivé de la

fonction, à son état activé, quand le conducteur de la pelle appuie sur le bouton adéquat au

clavier.

En fin de simulation un rapport d'erreurs est généré. C'est un fichier "fichier.log" au

format texte. On va y retrouver les numéros du test (les "requierments"), ainsi que des

indications nous permettant de savoir si le test a fonctionné correctement ou pas.

Si le test a échoué, ce fichier va nous indiquer, à quel endroit du test dans le scénario

Excel il y a une erreur. Il faudra alors déboguer soit le scénario, soit la description graphique

de la fonction pour obtenir un résultat final "OK".

Figure 31 : Simulation SCADE


Compréhension pour le débogage :

• Le test a échoué pour la spécification n° TC00740.9.

• Fail : erreur sur un ou plusieurs cycle machine.

• XLS row 30 : nous indique quelle ligne du fichier Excel est en cause.

• Step X : numéro du cycle machine où l'erreur est détectée.

• Fonction XXX : nom de la fonction mise en cause.

• Électrovanne 1 : nom de la variable qui a causé l'erreur.

• Qmax : le test n'est pas d'accord entre le scénario et la simulation sur la valeur max de

la variable.

Grâce à ces informations, on peut aisément situer où se trouve les erreurs dans le scénario.

Les différentes sources d'erreur possible :

• Le nom des variables entre le SCADE et le scénario ne sont pas les mêmes.

• On s'est trompé en entrant les valeurs Min et Max dans le fichier Excel.

• Le type de variable INT, REAL, BOOL n'est pas cohérent.

• L'utilisation de décalage dans le temps peut aussi être une source d'erreur possible.

Figure 32 : Test modulaire qui a échoué


Le but final des tests modulaires après débogage est d'obtenir un fichier de résultats "OK"

pour toutes les spécifications de la fonction testée.

Ici, le test TC00740.9 qui n'était pas bon auparavant est devenu "OK" après débogage.

• Pour les fonctions non sécuritaires, SIL0, une fois les tests modulaires effectués,

on peut passer directement aux tests sur la pelle.

• Pour les fonctions sécuritaires, SIL1 et SIL2, on doit effectuer des tests

d'intégration appelés aussi "Revers Sample trace".

4.8) Tests d'intégration :

On remonte encore d'une étape du cycle en V dans sa phase ascendante.

Ces tests fonctionnent sur le même principe que les tests modulaires.

Dans cette phase de tests, on va intégrer la fonction créée dans le projet complet de la

pelle qui comporte un grand nombre de fonctions. Cette fois-ci, les entrées de notre fonction

testées de façon manuelle, lors des tests modulaires, vont être connectées aux entrées et

sorties réelles de la pelle et au système entier c'est-à-dire la plateforme PME.

Figure 33 : Résultat final correct pour le test modulaire


La valeur des capteurs physiques sur la pelle va être prise en compte, la fonction va

calculer la valeur des sorties puis renvoyer ces valeurs sur les actionneurs physiques de la

pelle.

Dans le même principe, un scénario est réalisé sous Excel, mais cette fois le test n’est

plus effectué en simulation sur PC, mais sur un banc de test.

On va venir tester ce scénario sur le banc en chargeant le programme sur le master (unité

central de calcul) par l’intermédiaire d’une carte compacte flash.

• Port1 CF1 : contient le programme : "fichier.c" transformé en code

compréhensible par le master.

• Port2 CF2 : contient une carte de forçage des entrées et sorties de la pelle car tous

les éléments de la plateforme PME ne sont pas présents. Cette carte va simuler la

plateforme PME, pour pouvoir tester les fonctions comme si nous étions sur une

pelle.

Figure 34 : Principe des tests d'intégration

Figure 35 : Banc de test utilisé


Exemple d’une partie du scénario, pour le test d’intégration, d'une fonction :

Un test sera composé de 3 fichiers, qui seront chargés sur la carte CF2, grâce à une macro

Excel qui va générer les fichiers suivant :

• "fichie.smp" : qui comprend les spécifications ou "requirments" à tester.

• "fichier.pre" : qui fixe les valeurs des paramètres et mémoires

• "fichier.post" : qui va ordonner en fin de test le redémarrage du banc de test si cela

est demandé dans le scénario Excel.

De la même façon que pour le test modulaire un fichier d'erreur est généré, pour nous

indiquer quel test s'est mal passé et à quel endroit dans le scénario.

Ici le test a échoué sur la ligne 21 du scénario, correspondant au numéro de cycle 313.

La valeur minimum n'est pas cohérente entre le test sur le banc et la valeur dans le

scénario Excel.

Référence du test Nombre de cycles

machine Noms des entrées et

sorties réelles du programme

Figure 36: Scénario de tests d'intégration

Figure 37 : Test d'intégration qui à échoué


Après débogage des éventuelles erreurs on obtient un résultat final de test "OK"

Envoi des tests sur le master :

Les tests d'intégration sont placés dans la MMC CF2 du master.

Cette carte comprend donc les 3 types de fichiers post, pre et smp qui constituent le test.

Elle contient également les fichiers suivants :

• autoexec.frc : commande le processus d’exécution du test et force éventuellement les

valeurs de certaines variables.

• autoexec.shp : donne la liste des tests à effectuer et supprime les dossiers d’anciens

tests s’ils existent.

• Reboot : ordonne le redémarrage du master.

Figure 38 : Résultat final correct pour le test d'intégration


4.9) Test sur pelle :

C'est la dernière étape du cycle en V. Ces tests s'effectuent sur la pelle directement. Le

programme est chargé sur le master de la pelle, par l'intermédiaire de la carte compact flash

CF1. La personne responsable de la validation va vérifier que la fonction marche

correctement sur la machine. Toutes les spécifications de la fonction vont être testées, une à

une, en conditions réelles.

C’est la seule phase des tests que je n’ai pas pu réaliser moi-même. Car il faut être

habilité à prendre les commandes de la machine et avoir une autorisation Liebherr pour

pouvoir faire cela.

Pour nous aider lors de ces tests, on peut également connecter un PC en liaison Ethernet,

sur lequel on aura lancé l'application SCULI, dont nous avons déjà parlé. On pourra observer

les valeurs réelles des capteurs et des actionneurs. SCULI dispose de divers outils, tel qu'un

oscilloscope, qui peut s'avérer très utile pour analyser les mouvements de la pelle et pouvoir

imprimer des courbes.

Pendant ces tests, on répète plusieurs fois les mêmes mouvements, pour détecter

d'éventuelles erreurs que l'on ne peut pas voir sur le banc de test ou en simulation.

Un feedback nous est alors donné, par la personne des essais, pour savoir si tout est

correct, la fonction est alors définitivement validée, et le programme peut être "libéré" pour

être chargé sur les pelles, sur la ligne de production des machines.

Figure 39 : Exemple de courbe sous SCULI


5) Présentation du banc de test :

Voici le banc de test que j'ai utilisé tout au long de mon stage pour tester les différentes

fonctions logicielles que j'ai créées ou modifiées.

Le banc de test simple se compose d’un master PME qu’on alimente et auquel on

connecte respectivement le display et la caméra sur les ports Ethernets 3 et 2.

• Ce banc de test permet de faire les tests d'intégration. Le programme est chargé sur la

carte compact flash CF1, puis les tests se lancent tout seul et génèrent le fichier de résultat

à la fin, comme nous l'avons vu précédemment.

Grâce à un PC connecté en liaison Ethernet, avec l'application SCULI il est facile de

pouvoir visualiser les entrées et sorties de la fonction testée. On peut également activer ou

désactiver certains paramètres, comme par exemple la camera de recul, pour qu'elle s'affiche

sur l'écran.

Figure 40 : Banc de test utilisé


L'écran est tactile et permet au conducteur de changer de page de menu en appuyant

directement sur les touches sur l'écran.

Les principaux menus sont :

• Page 1 : Régime moteur, consommation de carburant

• Page 2 : Menu de la climatisation

• Page 3 : Surveillance des pressions et température d'huile

• Page 4 : Réglage des paramètres de la machine

• Page 5 : Menu optionnel

Figure 41 : Paramètre de la caméra activé.


Voici quelques exemples des pages de menu à l'écran.

Figure 42 : Menu de climatisation

Figure 43 : Surveillance des pressions et températures


6) Fonctions réalisées :

Voici une liste des fonctions principales que j'ai réalisées et testées.

Nom de la fonction Description

PumpsManageAutoId Permet aux pompes de débit d'huile hydraulique de s'ouvrir de façon progressive pour éviter de faire caler le moteur.

DisplayManageTouch Amélioration et généralisation, de la façon de prendre en compte un appui sur une touche de l'écran pour modifier une valeur.

ForceMenuOnDisplay En fonction de l'appui sur certaines touches du clavier, l'utilisateur peut mémoriser une page de menu préférée. Un simple appui sur cette touche permet de remettre la page mémorisée à l'écran.

TravelStraight Permet de commuter une électrovanne pour permettre de translater la pelle en ligne droite à l'aide d'une seule pédale.

TravelCorrection Correction du débit des pompes, pour la translation de la pelle.

SelectUserID Permet de mémoriser, plusieurs paramètres et préférences de la pelle, pour 5 conducteurs différents. Il suffit de sélectionner le bon conducteur et les paramètres mémorisés sont retrouvés.

TransferringControlAHS11 ToTiltBucket

Permet de transférer les commandes de l'outil, des pédales vers le joystick droit.


Conclusion :

Ce projet de fin d'études m'aura permis de mettre en application mes connaissances

acquises au cours de ma formation d'Ingénieur Génie électrique dispensée à l'INSA de

Strasbourg.

J'ai pu découvrir le logiciel SCADE, qui pour un besoin de développement de fonctions

logicielles pour application sécuritaire critique m'a paru être assez intuitif. Il permet de décrire

le fonctionnement d'une machine grâce à des fonctions graphiques qui simplifient la

programmation.

Dans un contexte économique en perpétuelle évolution technologique, ce logiciel me

parait correspondre parfaitement à un Ingénieur d'Études qui cherche à développer des

fonctions et programmes de manière simple, sans taper de code C, car c'est le logiciel qui se

charge de le faire.

Je suis satisfait de la confiance que l'on m'a accordée, dans la réalisation de mes fonctions

logicielles. J'ai pu mettre en application, le cycle en V, qui est un modèle conceptuel de

développement, qui permet de suivre les différentes étapes de développement d'un projet

informatique. Il permet en cas d'anomalie, de limiter le retour aux étapes précédentes.

Ce projet de fin d'études a été pour moi une véritable occasion de vivre le quotidien d'un

Ingénieur d'Études. Immergé au sein du service électrique du bureau d'études j'ai pu

progresser régulièrement, grâce à l'aide de mes collègues et à celle de mon tuteur.

Je suis également satisfait du fait que mon travail ait pu soulager l'équipe en place en

développant un certain nombre de fonctions qui ont pu être intégrées aux différents projets de

pelles.

Cette période de six mois au sein de la société LIEBHERR est une expérience efficace et

s'avère avoir été très formatrice tant sur le plan technique qu'organisationnel.

Documents

DÉVELOPPEMENT LOGICIEL MISE À JOUR DE …eprints2.insa-strasbourg.fr/1264/1/GE5E-2012-RuppLaurent-Mémoire... · de fin d’études en son sein. Je remercie le Docteur Ralf Späth,