Rapport d’Alternance  
Projet : ​QA Machine 
Florian Couderc 

 
 
Tuteurs : 
Patrice Dehan 
patrice.dehan@st.com 
Jerome Lescot 
jerome.lescot@st.com 
 
Responsable : 
Eric Picollet 
eric.picollet@st.com 

 
 
 
 
 
 

 
 
Septembre 2016 - Septembre 2019 
 1. Avertissements 
Ce rapport de stage contient des informations confidentielles appartenant à la société 
STMicroelectronics et, à ce titre : 
 
- Il ne peut être publié ou faire l'objet d'une divulgation, par quelque moyen que ce 
soit, à l'extérieur de l'établissement où est inscrit son auteur sans son accord écrit 
et celui de la société STMicroelectronics. 
 
- Il doit être utilisé et diffusé au sein de l'établissement uniquement pour les 
besoins de la soutenance de la thèse de son auteur et ne peut être reproduit qu'à 
des fins exclusives d'archivage auprès de l’établissement. 
 
Tout manquement par quiconque à ces dispositions est susceptible de causer un 
préjudice grave à STMicroelectronics qui pourra en obtenir réparation par la loi. 

2. Remerciements 
Merci à ​Patrice Dehan ​pour m’avoir tuteuré pour cette année et de m’avoir aidé 
sur la gestion de mon planning. 
 
Merci à ​Jérome Lescot ​pour m’avoir tuteuré pendant mes deux premières années 
d’alternance au sein de STMicroelectronics et de m’avoir permis d’entreprendre un projet 
de A à Z. 
 
Merci à ​Fabrice Garre p ​ our sa collaboration pendant les divers développements 
d’applications. 
 
Merci à ​François Lemery ​pour sa participation au développement de la QA 
Machine et de m’avoir fait découvrir cette entreprise. 
 
Merci à ​Eric Picollet p
​ our m’avoir accueilli au sein de son équipe ARCAD.  
 
Merci aux alternants ​Julien Marcotrigiano​, ​Elias Boulharts​, ​Remy Semonnay​, 
Jean-Antoine Gauzins​, ​Morgane Delmas​, W ​ illiam Schmitt​, ainsi qu’aux anciens alternants 
tombés au combat, ​Valentin Mele​, M ​ axime Lovichi​, ​Nathan De Pachtere​, ​Benjamin 
Bourgeais e ​ tL
​ aetitia Brochut ​pour leur jeune soutient au sein de cette entreprise et pour 
m’avoir apporté beaucoup de connaissances venant de leurs différentes spécialisations. 
 
 
 
 
 

1
3. Glossaire 
 
ST  ST​Microelectronics 

SC  S​emi-​Co
​ nducteur 

ARCAD  A​nalogy ​RF

​ C
​ ​omputer A
​ ​ided ​De
​ sign 

RF  R​adio F
​ ​réquence 

QA Machine  Q​ualification A
​ u
​ tomation M
​ achine 

CAD =
​ ​ CAO  C​omputer A
​ ​ided D
​ e
​ sign = ​Co
​ nception A
​ s​ sistée par ​Or​ dinateur 

Designer  Abus de langage pour dire c​ oncepteur ​en microélectronique. 

DK  D​esign ​K​it : Packages contenant tout le nécessaire à la conception de 

circuits microélectroniques 

MVC  M​odèle​ V​ue​ C​ontrôleur 

TDS  T​echnology to D
​ ​esign S
​ ​olutions 

TDP  T​echnology & D

​ ​esign P
​ l​ atform 

ESD  E​lectro​st​ atic D

​ ​ischarge 

ARTE  A​utomated R
​ ​egression T
​ e
​ st E
​ ​nvironment 

LSF  L​oaded S
​ ​haring ​F​acility 

IDE  I​ntegrated D​ ​evelopment ​E​nvironment : E

​ DI​ en français, E
​ ​nvironement 
de ​Dé​ veloppement ​In
​ tégré 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

2
 
 

4. Sommaire 
Avertissements 1 

Remerciements 1 

Glossaire 2 

Sommaire 3 

Introduction 6 

Présentation de l’existant 7 
L’Entreprise 7 
STMicroelectronics 7 
STMicroelectronics International 8 
STMicroelectronics France 11 
Pôle Minalogic 12 
Le site de recherche et développement 13 
L’Organisation - Equipe ARCAD 13 
Exemples de Kits 15 
L'Environnement 16 
Le cadre microélectronique et de l’entreprise 16 
Technologies utilisées 16 
VNC Viewer 17 
Load Sharing Facility (LSF) 18 
Synchronicity 19 
Les Logiciels de microélectronique 19 
Langages utilisés 21 
Matériel 23 

Le Projet 24 
Contexte antérieur 24 
Les Tests 24 
Flow de qualifications des Kits 25 
Automatisation des Tests 25 
Besoins 26 
Description de l’alternance 26 
Faciliter la création de Tests 26 
Automatisation des Tests 27 
Nouveau Flow de qualification des Kits 27 
Contraintes / Historique 28 

3
 Infrastructure ST 28 
Flow 28 
Économique 28 
Risques identifiés 29 
Réinventer la roue 29 
Temps des Flows 29 
Réticence au changement 29 
Systèmes existants 30 
Application ARTE 30 
Bridge ARTE / QA Machine 30 
Les applications du marché 30 
ARCAD Software on internet 30 
Critères de “succès” 30 

Analyse et Choix 31 

Technologies mises en place 31 
Méthode Agile (Codex / Tulip) 31 
Versionning: Git 34 
Python 35 
IDE 36 
Eclipse 36 
PyCharm 37 
Visual Studio Code 37 
C-Shell (csh) 38 
Framework Kraken 38 
Framework Django 41 
Channels 42 
Celery 44 
Rest Framework 44 
Serveur Web (VM) 45 
Services daemon pour Django 45 
Nginx 45 
Fonctions 46 
Les Tests 46 
Structure 46 
Exécution 49 
Evolution de l’interface 50 
Automatisation des Tests 54 
Crontab 54 
Scan des nouveaux Produits 54 
Récupération des nouveaux Tests 55 
Scan des Tests 55 

4
 Création des exécutables 55 
Exécutions des Tests 55 
Comparaison 55 
Envoi de rapports par e-mail 56 

Problèmes rencontrés 56 

Infrastructure ST 56 
Réticence au changement 56 

Conclusion 57 

Bibliographie et webographie 58 

Annexes 59 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

5
5. Introduction 
 
Je m’appelle Florian Couderc et voilà maintenant t​ rois années​ que je travaille en 
alternance pour l’entreprise ​STMicroelectronics à ​ ​Grenoble e​ t ​Crolles​.  
 
J’ai entamé un premier contrat pour mon​ BTS SIO s​ ur 2 ans de ​2016 à ​ 2
​ 018​, sous 
la responsabilité de J​ érôme Lescot​ Ingénieur en microélectronique, basé à Grenoble.  
 
Puis un deuxième contrat de 1 an de 2 ​ 018 à
​ ​2019 p
​ our ma Licence C ​ SIA ​sous la 
responsabilité de ​Patrice Dehan​ Ingénieur microélectronique lui aussi, basé à Crolles. 
 
Pendant ces trois années, j’ai pu assister à la création de plusieurs projets dont un 
principal qui est la raison de ma présence dans cette entreprise.  
 
Je présenterai dans ce rapport le logiciel créé et maintenu par mes soins sur ces 
trois années : la Q
​ A Machine​. 
 
Je développerai dans un premier temps une présentation de l’entreprise en 
France et à l’International, ainsi que l’équipe avec laquelle j’ai travaillé puis 
l’environnement dans lequel je me trouvais.  
 
Dans un deuxième temps je présenterai dans un contexte global et théorique le 
Projet pour ainsi présenter dans une troisième partie son aspect technique. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

6
6. Présentation de l’existant 
6.1. L’Entreprise 
6.1.1. STMicroelectronics 
 
L’entreprise STMicroelectronics est une société née de l’union de l’entreprise 
italienne SGS (Società Generale Semiconduttori) et de la société française Thomson 
Semiconducteurs en 1987. Cette fusion a donné naissance à une nouvelle société du nom 
de S​ GS – Thomson​.​ E ​ lle a ensuite été renommée ​STMicroelectronics e ​ n ​1998 ​à la suite du 
retrait de Thomson du capital. 
 
★ STMicroelectronics est une entreprise Franco-Italienne de s ​ emi-conducteurs​. Elle 
fait partie des ​leaders ​mondiaux de la microélectronique. C’est une entreprise qui 
fabrique​, et ​commercialise ​des p ​ uces ​pour divers clients. La clientèle est 
tellement diversifiée qu’aujourd’hui nous retrouvons des produits de l’entreprise 
partout autour de nous. 
 
★ Cette m ​ ultinationale ​fait face à de nombreux concurrents c’est pourquoi 
l’expertise ​que possède l’entreprise ne doit pas cesser de ​progresser​. Ainsi pour 
garantir un service o ​ ptimal ​et ​sécurisé S​ T s’est implanté dans plus de ​35 pays​. 
 
★ La direction a ​ dministrative ​de STMicroelectronics se situe à G ​ enève e ​ nS​ uisse​, 
tandis que sa direction o ​ pérationnelle ​est implantée sur le site principal du 
groupe à A ​ grate​, à côté de ​Milan​. 
 

Timeline événements STMicroelectronics 

 

7
 6.1.2. STMicroelectronics International 
 
★ STMicroelectronics ​est l’un des l​ eaders ​du marché du semi-conducteur avec un 
chiffre d’affaires de 6.59 milliards il fait partie des géants dans ce domaine. La 
compagnie est positionnée à la ​onzième ​place des plus g ​ ros fabricants mondiaux​.  
 
Totale Vente  Totale Vente 
2018F  2017  semi  semi  2018F/2017 
Entreprise  Siège Social 
Rang  Rang  conducteur  conducteur  % Ratio 
2017 ($M)  2018F ($M) 

1  1  Samsung  Corée du Sud  65,882  83,258  26% ▲ 

2  2  Intel  U.S.  61,72  70,154  14% ▲ 
3  4  SK Hynix  Corée du Sud  26,722  37,731  41% ▲ 
4  3  TSMC (1)  Taiwan  32,163  34,209  6% ▲ 
5  5  Micron  U.S.  23,92  31,806  33% ▲ 
6  6  Broadcom Ltd. (2)  U.S.  17,795  18,455  4% ▲ 
7  7  Qualcomm (2)  U.S.  17,029  16,481  -3% ▼ 
8  9  Toshiba  Japon  13,333  15,407  16% ▲ 
9  8  TI  U.S.  13,91  14,962  8% ▲ 
10  10  Nvidia (2)  U.S.  9,402  12,896  37% ▲ 
11  12  ST  Europe  8,313  9,639  16% ▲ 
12  15  WD/SanDisk  U.S.  7,84  9,48  21% ▲ 
13  11  NXP  Europe  9,256  9,394  1% ▲ 
14  13  Infineon  Europe  8,126  9,246  14% ▲ 
15  14  Sony  Japon  7,891  8,042  2% ▲ 

Top 15  323,302  381,16  18% 

(1) Fonderie, (2) Fabless 
   

8
 
★ Malgré une c​ oncurrence ​importante ​ST g
​ arde une place de leader dans le monde 
de la microélectronique et compte près de ​100 000 clients​ dans le monde, ce qui 
a pour conséquence d’avoir un large portefeuille de produits 
 

 
 
★ On retrouve ST sur 4 grands marchés :  
○ Celui de ​l’Automobile​, avec notamment des capteurs pour la conduite 
intelligente. 
○ De ​l’industrie ​pour les chaînes de production intelligente. 
○ Des ​appareils électroniques​ pour les Maison et Villes intelligentes. 
○ Des ​objets connectés​ avec des capteurs de caméra pour smartphone ou 
encore les capteurs de fréquences cardiaque pour montre connectées. 
 

 
   

9
 
★ ST c’est aussi 88 sites autour du globe réparties en plusieurs pôles d’activité : 
Recherche et Développement, Vente & Marketing, Front-End1 et Back-End2 

 
 
   

1
Fabrication des puces à partir du silicium
2
Packaging des puces fabriquées

10
 

6.1.3. STMicroelectronics France 

STMicroelectronics étant une entreprise Française et Italienne on retrouve 
différents pôles dans les deux pays.  
 
En France, ST s’est dispersé sur 9
​ sites​ dans différentes villes, répartie sur 
plusieurs pôles de compétences dont : 
 
- La vente, le marketing et le support client à P​ aris​,  
- La logistique à ​Genis​, 
- La Recherche et Développement, la conception et la production à T ​ ours​, ​Crolles​, 
Grenoble e ​ t ​Rousset 
- Le développement de produits et composants spécialisés à S ​ ophia Antipolis​ et 
Rennes​.  
 

 
 
 
 
 
 
 
 

11
 6.1.4. Pôle Minalogic 
Le pôle Minalogic est un pôle de c​ ompétitivité mondial ​basé à ​Grenoble e ​ t la 
région Auvergne Rhône-Alpes spécialisé dans les technologies du numérique.  
 
Face à la c​ oncurrence internationale​, la stratégie de ​Minalogic c​ onsiste à générer 
de la c​ ompétitivité p ​ ar l'innovation. Pour y arriver, les différents acteurs tissent entre 
eux des ​liens ​sous forme d ​ ’alliance ​entre e
​ ntreprises ​et de ​partenariat a
​ utour de ​projets 
communs et novateurs.  
 
Créée en 2005, la m ​ icroélectronique e ​ st, à cette période, pour la région de 
Grenoble, un véritable m ​ oteur ​technologique et i​ ndustriel​. La figure ci-dessous montre 
l’enjeu et le nombre d’acteurs que l’on peut retrouver dans ce pôle.  
 

 
 
Ce pôle permet de c​ réer ​des projets ​novateurs q ​ ui peuvent aboutir à des b
​ revets​, 
des ​publications e
​ t à la ​création d’emplois​. Depuis sa création ce pôle a généré près de 
3,605 milliards​ d’euros de bénéfice. 
 
 
 

12
 6.2. Le site de recherche et développement 
Comme on a pu le voir précédemment dans le pôle Minalogic, ​ST i​ nvestit 
régulièrement des sommes importantes dans la r​ echerche et développement​.  
 
Les recherches se font à tous les niveaux au sein de la compagnie. En effet 
certains vont développer de nouvelles techniques pour améliorer la production aussi 
bien en quantité qu’en qualité, mais d’autre vont essayer de trouver de nouveaux types 
de puces plus robustes et plus petites pour gagner en performance.  
 
ST apporte une importance particulière à la ​R&D​, car c’est le seul moyen de rester 
compétitif​. Le monde de la microélectronique est un domaine qui évolue extrêmement 
vite.  
 
90% de la R&D est réalisée en Europe dont le site principal est basé à Crolles, et 
environ 40% des effectifs de Crolles travaillent en R&D.  

6.2.1. L’Organisation - Equipe ARCAD 

L’équipe ​ARCAD (​ ​A​nalog R ​ ​f ​Co​ mputer A ​ i​ d D
​ ​esign) est une équipe de ​Recherche et 
Développement​. Elle est constituée d’une vingtaine de personnes permanentes (des 
ingénieurs et techniciens principalement) et de quelques alternants et stagiaires ​dont je 
fais partie​, tous réparties sur les sites de C ​ rolles ​et G ​ renoble ​en F​ rance ​ainsi que 
Greater-Noida e ​ n ​Inde​. 
 
Les ​Ingénieurs e ​ tD
​ esigners d ​ e cette équipe ont pour mission principale de 
développer des scripts ou d’ajouter des composants à des logiciels existants.  
 
Ces programmes que nous appelons des « K ​ its ​» sont dans la majeure partie des 
cas à destination des équipes ​internes d ​ e ​ST m
​ ais il arrive parfois que des clients 
externes ​aient besoin de nos K ​ its​.  
 
Les différents programmes maintenus au sein de l’équipe A ​ RCAD ​ont tous un rôle 
différent. Ils vont principalement aider les D ​ esigners à ​ réaliser les architectures des 
circuits intégrés. Certains vont extraire des données des fichiers pour les inclure dans un 
autre logiciel. D’autres vont permettre de lancer des tests sur les puces et circuits 
électriques et vérifier ainsi le bon fonctionnement du système et du « processus de 
fabrication ». 
 

13
  
Pendant toute la durée de mon alternance, j’ai t​ ravaillé ​au sein de l’équipe ​ARCAD 
dans la partie ​Design Verification​. L’équipe Design Vérification est dirigée par ​François 
Lemery​ et est composée actuellement de ​cinq Ingénieurs​ à temps plein et de t​ rois 
Alternants​ (dont moi-même) :  
 
➔ François Lemery : Ingénieur  
➔ Jérôme LESCOT : Ingénieur  
➔ Patrice DEHAN : Ingénieur  
◆ Florian COUDERC : Alternant en Licence CSIA 
➔ Fabrice Garre : Ingénieur  
◆ Julien MARCOTRIGIANO : Alternant en ecole d’Ingénieur IMT Atlantique 
➔ Sébastien MATHIEU : Ingénieur 
◆ Jean-Antoine GAUZINS : Alternant en ecole d’Ingénieur FELMA 
 

14
 Le rôle de cette équipe est de développer des K ​ its ​permettant de ​qualifier l​ es 
différents p​ rocessus a
​ vant que les s ​ chémas ​de ​circuits n ​ e partent en ​fabrication​. 
 
Certains développements ont été réalisés avec l’équipe ​Support & Productivity 
Tool​, équipe chargée du support des “​Design Kits (DK)​”, les ​Design Kits s​ ont des grands 
packages ​contenant toutes les ​informations e ​ t l​ ibrairies n ​ écessaires à la ​conception 
d’une ​puce microélectronique​ destinée aux ​Designers d ​ e ​ST​.  
 
Mon activité au sein de l’équipe ​ARCAD e ​ t ​Support & Productivity Tool​ a été 
transférée après un changement d’organisation dans une nouvelle équipe : ​Transversal 
Tooling​ qui se charge donc des outils transversaux aux différentes équipes de 
l’organisation.  
 
Nous ​fournissons d ​ es o
​ utils ​de ​développements e ​ t de T ​ ests ​à toutes les autres 
équipes pour une meilleur h ​ omogénéisation​ des ​développements​. 

6.2.2. Exemples de Kits 

Voici quelques exemples de kits développés par l’équipe ARCAD :  
 
- STECCK :​ (​ ​ST​atic E
​ ​lectrical ​Ch​ e​CK​)  
Permet de tester les fuites électriques d’un circuit intégré et donc ainsi 
vérifier le bon fonctionnement des circuits.  
 
- ESDCheckKit : 
Permet de vérifier si les circuits sont robustes aux différents événements 
ESD​ (Les décharges électrostatiques) 
 
- ADOC :​ ​(​Ad​ vanced ​D​esign O ​ p​ ened ​Ch ​ ecks) 
Est un logiciel regroupant de nombreux outils de tests pour faciliter la 
tâche des designers. Le but étant de permettre aux designers de lancer d’un clic, 
tous les tests dont ils ont besoin avant d’envoyer le circuit en fabrication  
 
- MosSelectKit : 
Est un outil permettant d’aider à la sélection du meilleur transistor 
possible en fonction de spécifications précises. Il extrait les performances d’un 
MOS (​M​etal O​ ​xide S​ ​emiconductor), et fournit des équations d’extractions 
adéquates ainsi qu’un affichage dédié des résultats.  
 
 
 
 
 
 
 
 

15
 6.3. L'Environnement 
6.3.1. Le cadre microélectronique et de l’entreprise 
J’ai é
​ volué d
​ ans un e
​ nvironnement ​très r​ estrictif c​ ar beaucoup de projets sont 
confidentiels ​et sont sur des s ​ ujets sensibles p
​ our certaines entreprises, par exemple 
des puces spéciales pour des satellites ou encore de nouveaux types de capteurs pour 
des caméras. Pendant certaines périodes de partenariat avec de grandes entreprises, il 
était par exemple interdit de prononcer leur nom directement au sein de l’entreprise, on 
les nommait par des noms de code. 
 
Certaines zones de l’entreprise sont inaccessibles et interdites dans le cadre de la 
confidentialité, par un exemple un étage entier restreint à certaines personnes car on y 
développe les futures puces pour carte bancaire.  
 
Mon alternance s’est déroulée dans un ​cadre d ​ em​ icroélectronique ​et donc 
compliqué ​si on ne vient pas de ce domaine ou que l’on ne l’a p ​ as étudié​. J’ai dû 
apprendre et comprendre les mots ​techniques e ​ t ​spécifiques à ​ ce cadre. Bien sûr, j’ai été 
bien encadré par mes tuteurs pour m’apprendre le ​lexique d ​ e la microélectronique et 
pouvoir réagir pendant une d ​ iscussion technique​. 
 
J’ai pu découvrir les différentes étapes de fabrication des circuits et puces 
microélectroniques, des processeurs, des capteurs, etc… et ainsi découvrir la complexité 
de cet univers. J’ai remarqué que le développement de programmes est indispensable 
dans ce type d’entreprise, d'où ma présence. 

6.3.2. Technologies utilisées 

Les développeurs/micro électronicien travaillent sur des ordinateurs qui tournent 
avec Windows 7 ou Windows 10 pour les plus récents. L'environnement Windows permet 
de : 
- Consulter ses e-mails 
- Faire des recherches sur ​l’intranet 
- Utiliser les différentes ​applications ​Web de l’entreprise disponible sur l​ ’intranet 
- Faire des recherches sur ​Internet 
- Utiliser les outils de B
​ ureautique ​: Word, Powerpoint, Excel 
- Communiquer ​avec les collègues à travers Skype Entreprise 
- Utiliser VNC Viewer 
 
Les ​développements e ​ t la c​ onception d
​ es ​circuits s​ e font sous un ​environnement 
Linux RedHat​ 6 ou 7, à travers ​VNC Viewer​. Sur les machines RedHat, nous avons accès à 
une multitude de produits et logiciels installés par l​ ’IT n ​ ous permettant de réaliser notre 
travail en donnant accès à : 
- Des ​IDE 
- Des logiciels de microélectroniques 
- Un service de “​Ferme de Machine​” dit L ​ SF​, expliqué plus tard. 

16
 6.3.2.1. VNC Viewer 
En utilisant le logiciel fabriqué par l’entreprise R
​ ealVnc ​: ​VNC Viewer​ (​Vi​ rtual 
N​etwork C ​ ​omputer) un système de visualisation et de contrôle de l'environnement de 
bureau d'ordinateur distant, nous pouvons accéder à l’environnement Linux RedHat.  
 
Il permet au logiciel client ​VNC ​de transmettre les informations de saisie du 
clavier et de la souris à l'ordinateur distant, possédant un logiciel serveur ​VNC ​à travers 
un réseau informatique.  
 
VNC e ​ st indépendant du système d'exploitation : un client ​VNC ​installé sur 
n'importe quel système d'exploitation peut se connecter à un serveur ​VNC ​installé sur un 
système d'exploitation différent ou identique ici W ​ indows ​vers L ​ inux Red Hat​.  
 
Plusieurs clients peuvent se connecter en même temps à un unique serveur ​VNC​. 
Parmi les utilisations de ce protocole, on peut citer l’accès aux logiciels de conceptions 
de circuit microélectroniques pour les ingénieurs de S ​ T​. 
 

 
Les machines distantes qui nous donnent accès à ​Linux RedHat​ sont toutes 
regroupées dans une “​Ferme de Machine​” qui traite toute les requêtes et permet 
d’allouer au personnel des ressources pour faire tourner des logiciels plus ou moins 
gourmand. 
 
Nous nous connectons d’abord sur des machines dite de “​login​” qui nous 
fournissent peu de ressources pour l’utilisation de logiciel.  
 
Cette première machine (​login​) va nous permettre de lancer des commandes qui 
nous permettrons d’acquérir un terminal sur une autre machine bien plus puissante pour 
pouvoir exécuter des logiciels qui demandes beaucoup de ressources. Ces commandes 
sont des commandes “​LSF​” pour “​ Load Sharing Facility​”.  

17
 6.3.2.2. Load Sharing Facility (LSF) 

 
Depuis notre terminal l​ ogin​, nous pouvons lancé une commande comme ceci: 
➔ b
​ sub -R "select[rh70] rusage[mem=16000]" -q gui -n 2 -P PIMDS "konsole" & 
 
Décortiquons la commande :  
- bsub ​: nom de la commande 
- -R​ : demande de ​Re ​ ssources 
- “select[rh​70 ​ ] rusage[mem=​16​000]”​ : on demande comme ressources une RedHat 
7​ avec 1​ 6​Go de RAM 
- -q​ : selection de la queue 
- gui :​ on veut utiliser la queue ​gui q ​ ui permet d’afficher des interfaces 
- -n​ : choisir le nombre de processeur 
- 2​ : ici on utilisera 2 processeurs 
- -P​ : sélection du P ​ r​ ojet 
- PIMDS​: il s’agit du nom du projet, il en existe beaucoup au sein de ST. 
- “konsole”​ : le programme qu’on veut lancer, ici le programme konsole 
 
Après cette commande, une “​konsole​” s’ouvrira avec les ressources demandées. Une 
“​konsole​” est un ​terminal p ​ lus élaboré que les autres. On aurait pu lancer la commande 
“​gnome-terminal​”, on aurait eu un autre t​ ype de terminal​. C’est à partir de c​ e terminal 
que nous allons pouvoir s ​ aisir des commandes​, ​logiciels o ​ u autre avec les ressources 
demandées, ici 2 ​ processeurs et 16Go de RAM​. 

18
 6.3.2.3. Synchronicity 
Synchronicity est un logiciel développé par D ​ assault Système​ et est un logiciel de 
conception collaborative de semi-conducteur. C’est un logiciel de v ​ ersionning ​comme ​git 
par exemple, mais fait pour la​ conception de semi-conducteur​.  
 
Ce logiciel permet aux ingénieurs de ​ST d ​ e partager et versionner des librairies de 
plusieurs Gigaoctets très rapidement. 
 
C’est un logiciel clé à la réalisation de mon projet, qui me permet de récupérer et 
de mettre à jour des tests rapidements et simplement. 
 
Synchronicity peut être utilisé par l’intermédiaire d’une interface graphique ou 
directement en ligne de commande, permettant ainsi de l’inclure dans des scripts. 

6.3.2.4. Les Logiciels de microélectronique 

Les ​Ingénieurs e ​ n microélectroniques de ​ST d
​ ispose d’une grande variété de 
logiciel permettant la réalisation de circuits électriques. Parmi eux nous retrouvons ​3 
grandes entreprises​ qui fournissent ces ​logiciels :​  
 
- Cadence : ​https://www.cadence.com 
- Synopsis : ​https://www.synopsys.com 
- Mentor Graphics : h ​ ttps://www.mentor.com 
 
Cadence ​et S ​ ynopsis s​ ont des concurrents directs au niveau de leur logiciel fournis : 
 
Cadence  Synopsis 

Virtuoso Framework Design​ :  Custom compiler​ (Framework) : 

Logiciel de conception de Schéma et  Logiciel de conception de Schéma et 
Layout, il permet par l’intermédiaire du  Layout, il permet par l’intermédiaire du 
langage propriétaire, le S​ kill​, de  langage​ Tcl/Tk​ de Customiser l’interface 
Customiser l’interface et les  et les fonctionnalités du Framework pour 
fonctionnalités du Framework pour  optimiser la conception des circuits. 
optimiser la conception des circuits. 

spectre :​ Simulation des circuits jusqu’aux  hsim :​ Simulation des circuits jusqu’aux 
transistors  transistors 
 
 
 
 
 
 
 
 

19
En microélectronique​ : 
- Un ​Schéma ​est une représentation des composants et connectiques d’un circuit 
électrique pour une fonctionnalité donnée. Le Schéma doit répondre aux 
spécifications d’un client qui seront vérifiées avec des simulations. 
 
- Un L
​ ayout ​est un ​Dessin q
​ ui correspond à la représentation physique du circuit 
qui servira à piloter les machines pour leur création en salle blanche. C’est la 
forme que prendra le s​ ilicium​ une fois fabriqué. 
 
Généralement, les C ​ oncepteurs ​dessinent en premier le ​Schéma ​de la puce pour 
spécifier le résultat attendu pour que les “​Layouteurs​” réalisent le ​Layout r​ eprésentant 
la vue physique du circuit conçu en amont. 
 
Schéma ​: L
​ ayout ​:  

 
 
Mentor Graphics​ fournit un logiciel du nom de ​Calibre​, permettant la réalisation 
des étapes de vérification des circuits conçus : 
 
❖ DRC (​ ​De​ sign​ R​ule​ C​heck) 
➢ Vérifie les règles du Dessin (​Layout​), est-ce que les règles de la fonderie 
sont respectées, le circuit en ​silicium c​ orrespondra au dessin du layout 
❖ LVS ​(​La​ yout ​Ve ​ rsus ​S​chematic) 
➢ Comparaison du L ​ ayout ​au ​Schéma​, est-ce que le ​Layout ​est conforme au 
Schéma ​en termes de nombre de c​ omposants e ​ t ​connectiques​. 
❖ PERC ​(​Pr​ ogrammable ​El​ ectrical ​R​ules C ​ h
​ eck) 
➢ Vérifier les règles électriques du circuit, pour rechercher des potentiels 
courts-circuits, coupures dans le circuit ou grille flottante ... 
 
Pour ces trois exemples, toutes les R ​ ègles de Fabrications/Design s​ ont d ​ éfinies e
​ t 
codées ​avec le langage de programmation ​Tcl/Tk​ imposé par ​Mentor Graphics​. 
 
Il existe une multitude de logiciels permettant de concevoir et vérifier une puce / un 
circuit microélectroniques, ceux présentés sont les principaux et les plus utilisées. 

20
 6.3.3. Langages utilisés 
Les I​ ngénieurs d
​ e mon équipe utilisent un panel de l​ angages de programmations ​très 
varié​. Parmi eux nous trouvons : 
 
Python  Maintenant le langage le plus utilisé de l’équipe, il permet de créer 
rapidement des petits scripts de calculs. Il est aussi principalement utilisé 
pour créer des interfaces graphiques complexes. 
 
Le P​ ython ​est un langage ​interprété​. C’est un langage ​orienté objet​, mais 
peut être aussi efficace en programmation procédurale.  
 
C’est un langage de h ​ aut niveau​ et un langage o​ pen source​ comme 
beaucoup d’entre eux. Il existe une ​communauté très active q ​ ui lui permet 
d’avoir de nombreux modules développés et ainsi de ​faciliter ​le 
développement de logiciels. 
 
Ce langage présente un très grand avantage qui est sa r​ apidité d’exécution 
sur pour l​ angage interprété​. Pour finir il a aussi l’avantage d’être très facile 
à lire grâce à sa syntaxe. 

Tcl / Tk  Un langage très connu au sein de l’équipe. Bien qu’ancien, il permet encore 
aujourd’hui de créer des interfaces complexes pour la m ​ icroélectronique​. 
Beaucoup de ​Kits o ​ nt été réalisées en T​ cl/Tk​. 
 
Il est beaucoup utilisé pour la création de R ​ ègles ​de ​Design p ​ our les 
circuits microélectronique. C’est un langage qui continuera d’être utilisé 
pour la maintenance de ces ​Règles 
 
Le langage ​TCL ​(T
​ o
​ ol ​Co
​ mmand ​L​anguage) est langage créé en 1988 qui a 
pour but de produire des scripts. C’est une technologie qui s’inspire 
principalement de ces prédécesseurs le langage C ​ ​, L
​ isp​, ​Sh ​et A
​ wk​. Le 
développement d’interfaces graphiques est possible avec ce langage en 
combinant avec la bibliothèque T ​ Ke
​ lle-même multiplateformes que l’on 
retrouve dans différents langages comme le ​Perl​, ​Python (​ ​TKinter​), ​Ruby 
et bien d’autres.  

21
 Cadence  Le S​ KILL ​est un dialecte du ​Lisp u​ tilisé comme langage de Scripting, il a été 
SKILL  créé en 1990 par C ​ ADENCE e ​ t est toujours très utilisé dans beaucoup de 
suites logicielles d’automatisation de la conception électronique de 
Cadence Design System. On retrouve donc le S ​ KILL ​assez souvent dans 
l’environnement ​ST​.  
 
Ce langage n’est pas documenté sur le web, les ingénieurs de ST utilisent 
les documentations écrites de Cadence. 
 
Ce langage est principalement utilisé pour créer des plugins aux autres 
logiciels de l’entreprise C​ adence​. Il surtout utilisé pour le logiciel ​Virtuoso​, 
permettant de customiser l’interface du ​Framework e ​ t d’enrichir la 
conception de circuits. 

C-Shell  Le s ​ hell e​ st un mini-langage de programmation intégré à ​Linux ​et 

utilisable par ​consoles a ​ fin d’effectuer des actions habituellement difficiles 
à réaliser dans un environnement graphique. 
 
Le c​ sh e ​ st un ​shell Unix b​ asé sur le C
​ r​ endant compatible ce dernier avec 
le S
​ hell​. Il lui ajoute plusieurs améliorations comme la complétion des 
noms de fichier ou l’édition de commande en ligne. 
 
Le C ​ -Shell ​est utilisé pour tous les scripts d'exécution de S​ T​. Ce langage 
nous permet de paramétrer très rapidement un ​environnement d ​ e travail. 

C / C++ /  Ces langages très connus pour leur v ​ itesse d’exécution​ ont parfois été 
Cython  utilisés pour des programmes qui demandaient une certaine ​rapidité ​ou 
exigeaient une certaine ​sécurité​. 

22
 6.3.4. Matériel 
Comme matériel de travail, je disposais d’un ordinateur portable ​HP EliteBook 
8460p​, p ​ ratique e
​ t f​ onctionnel​, c’est un ​vieil o
​ rdinateur q
​ ui ne peut pas faire tourner de 
logiciel gourmand en ressources, il tourne sous​ Windows 7​ (Parfait pour utiliser ​VNC 
Viewer​). 
 
Je disposais aussi d’un deuxième écran ​HP L2445w​ de 1920x1200p. Et enfin un 
téléphone fixe pour faire du support si besoin. 
 
Tous les employés de ​ST s​ ont en possession d’un téléphone fixe ou portable pour 
pouvoir communiquer. Les autres I​ ngénieurs ​de mon équipe ont récemment changé 
leurs ordinateurs portable ou fixe contre de nouveaux permettant la migration du 
système d’exploitation​ Windows 7​ vers ​Windows 10​, car rappelons le, ​en Décembre 
2019, Windows 7 ne sera plus supporté par Microsoft et ne sera plus fournis en mise à 
jour de sécurité​. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

23
7. Le Projet 
7.1. Contexte antérieur 
7.1.1. Les Tests 
Chaque I​ ngénieur ​de l’équipe A ​ RCAD e ​ st en charge d’un ​Kit​. Ces K ​ its​ doivent 
évoluer suivant les besoins des ​Designers​, les I​ ngénieurs ​suivent alors des ​RoadMap3 de 
livraison de nouvelles fonctionnalités.  
 
Pour livrer une fonctionnalité, un ​Ingénieur d ​ oit la ​valider​ et la q​ ualifier​. Pour cela, 
il doit créer des ​Tests p ​ our son ​Kit q ​ ui permet de t​ ester la non régression​ des autres 
fonctionnalitées du K ​ it​. 
 
Jusqu’à présent, chaque ​Ingénieur r​ éalisait dans s ​ on​ espace de travail des T ​ ests 
qui permettaient de v ​ alider​ et q ​ ualifier​ les nouvelles fonctionnalités. Ils devaient les 
exécuter à la ​main​, ce qui leur prenait un certain temps hebdomadaire pour réaliser tous 
leurs T ​ ests ​avant la livraison d’une nouvelle fonctionnalité. 
 
Certaine fois, les T ​ ests ​n’étaient même pas lancés avant une livraison par 
manque de t​ emps​ pour tout valider, certains t​ ests ​pouvant durer plusieurs heures voire 
jours ! 
 
De plus chaque I​ ngénieur ​avait sa manière de faire ses T ​ ests​, ce qui peut être 
illisible pour d’autres I​ ngénieurs ​et donc aucun support lors de l’absence de l’auteur des 
Tests​. 
 
Nous nous trouvions dans un contexte ​dangereux ​car si une régression surgissait 
et qu’elle n’était pas détectée tout de suite, un ​Designer​ pouvait alors commettre une 
faute dans la conception d’un circuit et une erreur à l’impression des circuits sur silicium 
peut coûter des millions de dollars. 
 
Il faut alors à tout prix h ​ omogénéiser​ les T ​ ests​ et les rendre a ​ utomatiques​ pour 
qu’à tout instant n’importe quel I​ ngénieur p ​ uisse corriger les ​Tests​ ou K ​ it ​d’un autre 
après visualisations des rapports de ​Tests​. 

3
Calendrier de lancement / Feuille de route

24
 7.1.2. Flow de qualifications des Kits 

 
 
Chaque I​ ngénieur​ développe ses propres tests et annonces à voix haute lors des 
Weekly4 s​ i les tests sont b​ ons ​ou ​non​.  
 
Les ​Ingénieurs r​ éitèrent leurs ​Tests ​s’il échoue ou corrige le K
​ it ​si nécessaire. Les 
autres ​Ingénieurs n ​ e peuvent pas ou peuvent difficilement réutiliser ou corriger les ​Tests 
des autres. 

7.1.3. Automatisation des Tests 

Il n’y avait aucune Automatisation s
​ tandardisée d
​ es Tests. Chaque Ingénieur 
relance ses tests si nécessaire pour une nouvelle fonctionnalité. 
Certains ont des scripts automatiques tous les jours, c​ hacun sa façon de faire​. 
 
 
 
 
 

4
Réunion hebdomadaire de l’équipe le mercredi matin

25
 7.2. Besoins 
7.2.1. Description de l’alternance 
 
Intitulé du Poste : 

- Alternance : Spécification, développement, qualification et déploiement d’un 

environnement de test automatique pour nos produits analogiques développés 
au sein de l’équipe ARCAD (Analog / RF CAD) 

Description : 

- “Le candidat sera basé sur le site de Grenoble (ST Polygone), au sein de l'équipe 
ARCAD qui développe des outils CAO pour la conception de circuits analogiques 
et mixtes. Le travail demandé comprend la spécification et la mise en place d'un 
environnement de tests automatiques afin de qualifier nos kits (produits 
développés en interne) avant leur distribution dans les équipes de conception 
situées dans l'entreprise ou à l'extérieur. Les spécifications, le choix du langage 
de programmation (ex: python) seront discutés avec les membres de l'équipe. 
Le développement du moteur de test se fera ensuite en collaboration avec un 
(ou plusieurs) développeur(s) et sera validé de manière continue par les 
utilisateurs. Le candidat prendra donc en charge les phases de spécification, de 
développement, de qualification jusqu'au déploiement de l'outil.” 

E-Mail du 28 juillet 2016 

7.2.2. Faciliter la création de Tests 

Le besoin majeur pour l’équipe est de pouvoir créer facilement des ​Tests a ​ vec 
une i​ nterface​. ​L’architecture d ​ es ​Tests d
​ oit être ​standardisé​ de manière à ce que chaque 
Ingénieur ​puisse lire et comprendre les T ​ ests ​des autres et ainsi les c​ orriger ​ou les 
réutiliser s​ i besoin. 
 
Chaque T ​ est ​est géré avec le logiciel S ​ ynchronicity​ ​pour tous les rassembler au 
5
même endroit (sur un ​Vaults ). Les ​Ingénieurs ​ne doivent plus avoir leurs T ​ ests ​stockés 
dans leurs espaces personnels de travail pour​ faciliter leurs exécutions​ en cas d’absence 
de l​ ’Ingénieur​. 
 
 
 
 
 
 

5
Coffre en français, serveur de stockage des données du logiciel Synchronicity

26
 7.2.3. Automatisation des Tests 
Deuxième besoin, créer un système de récupération des Tests sur le logiciel 
Synchronicity pour les relancer automatiquement si besoins en détectant les nouvelles 
versions des différents produits nécessaire pour un test et ainsi créer un rapport 
donnant le statut du Test. 
 

7.2.4. Nouveau Flow de qualification des Kits 

 

 
*Check-In : Commande d’envoie des données sur Synchronicity 
*Populate : Commande de récupération des données sur Synchronicity 

27
 7.3. Contraintes / Historique 
7.3.1. Infrastructure ST 
L’infrastructure de ​ST é
​ tant très sécurisée, je n’avais pas accès à internet 
directement depuis l’environnement ​Linux Red Hat​, je ne pouvais par exemple pas 
télécharger des packages spécifiques permettant la simplification de mon code. 
 
L’infrastructure ST oblige la création de produits finis dit “​Produit Unicad​”, qui 
respects une certaine architecture permettant d’être distribuable dans tous les sites de 
ST ​autour du monde. Ces “​Produits Unicad​” ne permettent d’embarquer que les logiciels 
installés sur les machines Linux ce qui peut être contraignant si un autre logiciel est 
nécessaire et non installé sur l’infrastructure. 

7.3.2. Flow 
Pour pallier la contrainte de l'infrastructure de ​ST​, nous pouvons suivre des 
“​Flow​” d’installation de logiciels permettant l’accès et l’exécution de ces logiciels une fois 
installés et compilés pour les machines de l’environnement ​Linux Red Hat.  
 
Ces ​Flows s​ ont parfois complexes à demander et peuvent prendre é ​ normément 
de temps​ avant d’être lus et encore plus pour être acceptés. 

7.3.3. Économique 
Bien que ​ST i​ nvestisse beaucoup en ​R&D​, les équipes ​TDS/TDP​ sont parfois 
contraintes à devoir utiliser seulement les logiciels et packages en o ​ pen source​ pour ne 
pas avoir à payer de licence supplémentaire par utilisateur. 
 
Par exemple, pour la suite de ​JetBrain ​avec ​l’IDE P
​ yCharm​, très prisé des 
développeur python, nous n’avions le droit qu’à la version “​Community​” avec des 
fonctionnalités bridées par rapport à la licence P​ rofessionnel​. 
 
 
 
 
 
 
 
 
 

28
 7.4. Risques identifiés 
7.4.1. Réinventer la roue 
Dans ce rapport, j'introduirai le ​Framework K ​ raken​ q​ ui a été utilisé pour créer 
l’interface de création de ​Tests​.  
 
Ce ​Framework ​nous permet d'éviter de faire comme le faisaient les Ingénieurs 
d’habitude. C’est à dire ​coder dans son coin des fonctionnalités et ne pas en parler aux 
autres​. Cette manière de faire créait des situations où le t​ ravail a ​ vait été ​fait 2 fois​ voire 
plus, résultant à une p​ erte de temps​ suivant la quantité de code écrite. 
 
Le risque identifié était de collaborer avec des personnes ne communiquant pas 
leur travail pour pouvoir le ​réutiliser ​et ainsi ne p
​ as réinventer​ la roue. Nous avons aussi 
dû identifier les b
​ esoins ​de notre application et ​vérifier e​ n ligne les produits et p ​ ackages 
existant ​nous permettant de faciliter notre d ​ éveloppement​. 

7.4.2. Temps des Flows 

Le temps d’acceptations des différents F ​ lows ​était un ​risque très élevé​, il a fallu 
faire pression pour que certaines p ​ rocédures accélèrent a ​ vant la fin de mon alternance 
pour f​ inir ​la m
​ ise en production​ de toutes les applications. 

7.4.3. Réticence au changement 

Une importante partie de mon ​projet a ​ été de faire accepter cette nouvelle 
application au sein de l’équipe, chose qui n’a pas été facile au début, car chacun avait sa 
façon de faire.  
 
Il a fallu accompagner les ​Ingénieurs ​de l’équipe et les faire participer au 
développement de certaines fonctionnalités pour l​ es intégrées au projet​ et ainsi leur 
faire accepter l’application. 
 
 
 
 
 
 
 
 

29
 7.5. Systèmes existants 
7.5.1. Application ARTE 
L’application ​ARTE​ (​A​utomated R
​ ​egression T
​ e
​ st E
​ ​nvironment) est une application 
développée par l’équipe S ​ upport & Productivity Tool​, cette application permet de tester 
la régression des différents produits présents dans un D ​ esign Kit​.  
 
Malgré sa puissance et son efficacité, cette application n’est pas adaptée aux K ​ its 
Analogue ​de l’équipe ​ARCAD​. Il a donc été préférable d’avoir un système propre à 
l’équipe ​ARCAD p​ our créer des ​Tests  

7.5.1.1. Bridge ARTE / QA Machine 

Un “Bridge” c’est à dire une p ​ asserelle ​a été réalisé entre le système A ​ RTE e​ t la 
QA Machine​. Cette p​ asserelle ​permet le lancement a ​ utomatique ​de certains t​ ests 
suivant leur configuration, permettant aux Tests sur l’application A ​ RTE ​de valider des 
Design Kits​ suivant les ​Kits d
​ e l’équipe A
​ RCAD​. 

7.5.2. Les applications du marché 

7.5.2.1. ARCAD Software on internet 
Petite anecdote, une entreprise du nom de ​ARCAD Software​ développe un logiciel 
nommé ​DOT Verifier​ qui est un​ outil de test de régression​. 
 
Ce logiciel étant payant et demandant beaucoup de support de la part de 
l’entreprise, il n’a pas été accepté de l’utiliser. 
 
Cette entreprise n’a rien à voir avec STMicroelectronics. 

7.6. Critères de “succès” 

Les critères de succès du projet son : 
 
★ Une ​interface de création de tests fonctionnels 
★ Un ​script automatique permettant la relance des tests pour détecter les 
régressions 
★ L​’acceptation du logiciel par l’entièreté de l’équipe 
 
 
 
 
 
 
 
 
 

30
8. Analyse et Choix 
8.1. Technologies mises en place 
8.1.1. Méthode Agile (Codex / Tulip) 
Chez S ​ T​, les méthodes de gestion de projet pour l​ ’informatique ​sont fortement 
inspirées d ​ es méthodes de la ​microélectronique​.  
 
Actuellement, la compagnie possède ​un outil​ de gestion projet : « C ​ odex ​». Cet outil est 
développé par une entreprise extérieure du nom de « ​Tuleap » ​ .  
 
Celle-ci propose une boîte à outils qui permet de gérer un 
projet informatique de son lancement à sa livraison.  
 
Lors du lancement d’un projet par défaut « Codex » propose 
les outils suivants :  
 
- Une partie ​administration q ​ ui permet d’ajouter, modifier ou 
même supprimer certains outils du projet afin de répondre 
précisément aux attentes.  
 
- Un ​forum p ​ our échanger entre utilisateur et développeur. 
 
- Une zone de ​stockage q ​ ui permet de partager les fichiers 
entre développeurs  
 
- Un système de « N ​ ews » ​ où les utilisateurs peuvent 
retrouver toutes les mises à jour faites sur le projet.  
 
- Un système de « T ​ racker ​» qui permet au développeur de 
récupérer les requêtes des utilisateurs tel que les bugs.  
 
- Un ​Tableau Agile​ pour utiliser la méthode ​Kanban o ​ u 
Scrum​. 
 
- ​Git q
​ ui est un outil de gestion de données et de versionning de code. 
 
 
 
 
 
 
 
 
 

31
 La méthode Agile est un ensemble d’outils qui permet à une équipe de 
développement de répondre au mieux à la demande du c​ lient​. A l’inverse, elle permet au 
client ​de s’exprimer au mieux sur les exigences et ainsi avoir un projet cohérent avec ses 
besoins. Dans le cadre de ST, les clients sont la ​plupart du temps les collègues​.  
 
ST ​possède un outil très peu utilisé « ​l’Agile Dashboard »
​ . C’est une application 
que l’on peut activer dans C​ odex​. Il permet d’avoir un support informatique pour mettre 
en place la méthode ​SCRUM​.  
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

32
Sur cette page d’accueil on retrouve les premiers éléments de la méthode Agile :  
- Le « B ​ acklog ​» qui est l’endroit où l’on stocke les « S
​ tories ​». Une « S
​ tory »
​ est 
une fonctionnalité du logiciel à développer. Elle est détaillée et assignée à 
quelqu’un de l’équipe pour être développée  
 

 
 
- Les « ​Releases » ​ que nous découvrons dans les « S ​ prints ​» de la méthode Agile. 
Un « S
​ print ​» est une période de temps qui se limite entre 1 et 4 semaines et qui 
contient un nombre de « ​Stories » ​ à développer. Après cette période une « 
Release ​» ou l​ ivraison ​en français doit être faite pour le client. Cette livraison 
contient toute les « S ​ tories ​» développées  

33
 8.1.2. Versionning: Git 
“Git est un logiciel de gestion de versions décentralisé. C'est un logiciel libre créé 
par Linus Torvalds, auteur du noyau Linux, et distribué selon les termes de la licence 
publique générale GNU version 2. En 2016, il s’agit du logiciel de gestion de versions le plus 
populaire qui est utilisé par plus de douze millions de personnes.” 
 
Toujours sur Codex, cet outil met à disposition un gestionnaire de ​repository Git6.  
 

 
 
Nous pouvons faire une demande de​ repository Git​ pour gérer les versions de 
​ sh 7qui nous 
notre code. Une fois le repository créé, nous avons accès à une adresse s
permettra de clone, commit, push, etc… sur ce repository. 

 
 

6
Dépot distant : emplacement des données sur un serveur distant.
7
​SSH​ : ​S​ecure ​SH​ell = protocole de connexion à distance sécurisé

34
 8.1.3. Python 
Python ​est un l​ angage ​de programmation i​ nterprété​, c’est à dire que l’on n’a p
​ as 
besoin de compiler le code pour pouvoir l’exécuter​. 
 

 
Historiquement l’équipe A ​ RCAD ​développais leur K ​ its ​en T
​ cl/Tk​, mais ce langage 
commence à vieillir sérieusement et l’exécution de code ​Tck/Tk​ est par exemple plus 
lente que le python. Maintenant, l’équipe A ​ RCAD ​consacre l​ ’écriture ​de code en ​Tcl/Tk 
uniquement pour les ​Framework microélectronique​. 
Un autre langage beaucoup utilisé pour la réalisation de ​Kits ​était le P ​ ython d​ ans 
sa version ​2,​ plus précisément, la version​ 2.7 ​sortie le ​3 Novembre 2008​, cette version 
ne recevra ​plus de patch de correction​ à partir du 1​ er Janvier 2020​. 
 
Python ​est un langage pratique car nous n’avons p ​ as besoins de le compiler​, 
l'Infrastructure S​ T, t​ ournant sur ​Linux Red Hat,​ supporte très bien l’exécution de P ​ ython​. 
Une quantité intéressante de packages existe sur le site ​Pypi​ q ​ ui répertorie tous les 
packages compatibles avec P ​ ython ​et ses différentes versions. 
 

 
Compteur du sites h
​ ttp://www.pypi.org 
 
C’est pour cela que nous avons choisi le langage ​Python 3.5​ dans un premier 
temps, puis ​Python 3.6​ à sa sortie le ​23 Décembre 2016​. 
 
Grâce à la librairie avancé de packages P ​ ython Anaconda​, nous avons pu utiliser 
par exemple le packages ​PyQt​ permettant de créer des interfaces basées sur Q ​ t​ une A
​ PI 
orientée objet développée à la base en C ​ ++​. 
 
 
 
 
 
 
 

35
 8.1.4. IDE 
Les ​IDE​ soit “​In
​ tegrated ​D​evelopment E ​ ​nvironment” c’est à dire ​EDI​ en français, 
E​nvironnement de D ​ ​éveloppement I​ n ​ tégré, comprenons par là une ​interface intelligente 
capable de ​comprendre e ​ td ​ ’interpréter l​ es ​lignes de codes​ écrite dans un certain 
langage.  
 
Les I​ DE​ sont fortement ​utilisés p ​ ar les ​développeurs c​ ar ils permettent de relever les 
erreurs ​très ​rapidement a ​ vant même d ​ ’exécuter ​le p​ rogramme développé​. 
 
Pour ce projet nous avons choisis le langage ​Python​, nous somme passé par 3 ​  
IDE​ différents jusqu’à présent, nous suivions l’arrivé des nouveaux I​ DE s​ ur 
l’infrastructure ​ST​ au fil des années. 

8.1.4.1. Eclipse 

 
 
Nous avons dans un premier temps utilisé l’IDE Eclipse, qui est à la 
base un I​ DE ​fait pour le développement J​ ava​, ​C,​ ​C++​ ou même P ​ HP​. Un 
alternant a intégré le module P ​ yDev ​dans ​Eclipse p ​ ermettant l’interprétation 
du code P ​ ython​. 
Python ​pouvait donc être lancé directement depuis ​l’IDE​, avec un 
débogueur ​intégré ainsi que l​ ’interprétation ​en direct d ​ ’erreurs ​en cas de 
faute d​ e frappe. 
Malgré l'efficacité d
​ ’Eclipse​, il a été préférable de changer ​d’IDE ​car celui-ci était 
fait pour un autre langage​ à la base en plus de ​consommer beaucoup​ de ​RAM​. Nous 
étions obligés de relancer assez souvent l’interface pour éviter les “​Freeze​” intempestifs 
de cette dernière. 
 
 
 
 
 
 
 

36
 8.1.4.2. PyCharm 

 
 
PyCharm ​est un I​ DE f​ aisant partie de la suite de ​JetBrain​. Il est fait spécialement 
pour le P​ ython e ​ t lui accorde une g ​ rande quantité ​de ​fonctionnalités p ​ ermettant d’être 
vraiment e ​ fficace ​sur le l​ angage​. 
 
PyCharm ​est livré avec différentes formules, chez S ​ Tn​ ous avons la formule 
“​Community”​, la version g ​ ratuite ​de l​ ’IDE ​pour les projets O​ pen-source ​ou n ​ on 
commerciaux​. Cette version donne ​beaucoup plus ​de ​fonctionnalités q ​ u’​Eclipse​. 
 
Nous avons donc utilisé pendant un long moment, même encore maintenant cet 
IDE​. Mais après l’évolution de certaines de nos applications, nous avons été amenés à 
devoir écrire du H ​ TML​, ​CSS e ​ t J​ avascript e ​ n même temps que du P ​ ython​. L’interprétation 
et le d
​ ébogage ​de ces l​ angages ​sont aussi intégrés à cet I​ DE​, mais seulement pour la 
version “​Professionnel” d ​ e l’IDE. ​Une discussion est en cour avec le m ​ anagement ​pour 
débloquer ​des licences professionnelles de cet I​ DE​. 
 
En attendant, nous avons décidé de passer sur un autre ​IDE p ​ our nos 
développement ​HTML​, ​CSS e ​ t J​ avaScript​. 

8.1.4.3. Visual Studio Code 

 
Visual Studio Code​ plus communément appelé “​Code​” est un éditeur de code 
“​extensible​” développé par M ​ icrosoft ​pour W
​ indows​, L
​ inux ​et ​MacOS​. 
 
Nous avons décidé après ​PyCharm ​de passer sur cet I​ DE c​ ar il est entièrement 
personnalisable g ​ râce à son m ​ arché d’extension ​créé par la ​communauté e ​ t qui permet 
de faire tout ce que les autres ​IDE ​font mais g ​ ratuitement​. 
 
Grâce à C ​ ode​, nous pouvons développer facilement nos nouvelles applications en 
HTML​, C​ SS​, ​JavaScript e​ t ​Python e​ nsemble avec toutes les fonctionnalités de débogage. 
 
Il est tout de même fort p ​ robable ​que l’équipe r​ etourne ​sur P
​ yCharm s​ i des 
licences Professionnels s​ ont ​débloquées ​par les managers. 

37
 8.1.5. C-Shell (csh) 
Le ​C Shell​ ou c​ sh ​est un ​interpréteur d​ e commandes informatiques pour les 
systèmes L ​ inux​. C’est une é​ volution ​du s
​ hell ​(s
​ h​) qui utilise une syntaxe proche du 
langage C​.  
 
Le ​C Shell​ est installé par défaut sur les machines​ Red Hat​ de ​ST p ​ ar l​ ’IT​. 
Pour ce projet nous avons utilisé quelques scripts ​csh p ​ our lancer des commandes 
propres à l’infrastructure de ​ST​. 
 
Par exemple le lancement d’un ​script csh ​interprétant les commandes pour le 
logiciel S
​ ynchronicity​. 
 
Le ​Python ​permet l’exécution de script directement dans son code dont le c​ sh​. 

8.1.6. Framework Kraken 

Le ​Framework Kraken​ est un projet très vaste et m ​ ériterait u
​ n ​rapport complet​ à 
son sujet. Une partie de ma mission à été de le m ​ aintenir ​et de lui ​ajouter d​ es 
fonctionnalités​. Il a été c​ réé ​par un a
​ ncien alternant d​ e ​ST, Nathan De Pachtere​. 
 

 
 
Ce ​Framework ​facilite la création d’interface en P ​ ython ​basé sur l’architecture 
MVC​ utilisant la librairie graphique P
​ yQt. I​ l ​facilite ​le d
​ éveloppement e ​ t la m
​ aintenance 
d’un logiciel, permet de ne ​pas réinventer la roue​ et ainsi g ​ agner du temps​. Il ​encadre l​ e 
développement, ​uniformise ​l'architecture des d ​ éveloppements ​et permet d'instaurer des 
normes d ​ ans les d
​ éveloppements d ​ e l’équipe. 

38
 
Kraken n ​ ous a permis dans un premier temps de réaliser l’​interface graphique​ de 
création d​ eT ​ ests​. Cette i​ nterface ​a é​ volué e​ nm ​ ême temps​ que le F ​ ramework évoluait​. 
Le développement de la Q ​ A Machine​ a notamment permis de tester certaines 
fonctionnalités d ​ uF​ ramework ​avant la mise en ​productions d ​ e ces dernières.  
 
La Q​ A Machine​ est la deuxième interface créée au sein de ​ST ​grâce au 
Framework Kraken​. 
 
Le ​Framework ​fonctionne sur le développement de “​Bundle​” que nous pouvons 
partager ​entre projets. Lors du développement de la Q ​ A Machine​, ​3 Bundles​ ont vu le 
jour pour ensuite être ​partagés​. Ces différents B ​ undles s​ ont utilisés dans ​d’autre projets 
de l’équipe ​ARCAD​. 
 
Grâce à ce ​Framework​, les membres de l’équipe A ​ RCAD ​se ​partagent ​dorénavant 
leur ​création ​et d ​ écouverte ​en P​ ython p ​ ar l’intermédiaire de K ​ raken​. 
 
Au début de mon alternance, le F ​ ramework ​ne proposait que la conception 
d’interface grâce à la librairie P ​ yQt​. La création d’interface en ​PyQt ​pouvant d ​ evenir 
lourde après l’instanciation d’une grande quantité d’objets​, il a été décidé de faire évoluer 
le ​Framework ​pour lui donner un nouveau moteur graphique permettant la création 
d’Interface e ​ n ​HTML​, C ​ SS ​avec l’interprétation de ​JavaScript​ et beaucoup plus léger à 
exécuter. 
 
J’ai donc été en charge d’octobre 2018 à Janvier 2019 de la création de ce moteur. 
Nous nous retrouvons avec ​2 archétypes d’interface​ créé avec ​Kraken ​dans l’équipe : l​ es 
interfaces en P ​ yQt​ et celles en H ​ TML​. 
   

39
 
Exemple d’interfaces : 
 
En PyQt : 

 
 
La même en HTML : 

 
 
Le moteur HTML, CSS & JavaScript est basé sur le moteur Chromium de Google. 

40
 8.1.7. Framework Django 

 
 
Django ​est un F ​ ramework Web o ​ pen source en ​Python​. Il a pour but de rendre le 
développement d’application web simple et rapide. Il est utilisé pour développer des sites 
très connus tel que P ​ interest​ ou encore I​ nstagram​. 
 
Le but de la Q ​ A Machine​ est de f​ ournir d ​ es r​ apports détaillés​ de T
​ ests ​ayant été 
exécutés ​automatiquement ​pendant la nuit. Nous avons alors décidé de créer un s ​ ite 
web​ d​ ynamique g ​ râce à ​Django p ​ our servir les ​résultats t​ out prêts ​le matin​. 
 
Django ​nous a permis de c​ réer facilement e ​ t ​rapidement c​ e site web sans aucune 
connaissance de base du Framework. Il rentre dans le cadre de s ​ tructuration ​des projets 
de l’équipe ​ARCAD e ​ n étant un ​Framework​. 
 
Depuis la dernière mise à jour du F ​ ramework Kraken​, les applications faites avec 
Kraken c​ ontiennent des ​vue/templates​ en h ​ tml ​pouvant être ​réutilisés s​ ur D​ jango​. Cela 
appuie encore plus la notion de p ​ artage ​de c​ onnaissance ​au sein de ​l’équipe​. 
 
Le ​Web ​étant un domaine très large et demandant des connaissances bien 
spécifiques, les Ingénieurs de S ​ Tn ​ ’étaient à la base pas enclins à utiliser ce genre 
d’outils, ce qui fait que l’infrastructure S ​ Tn ​ e propose pas automatiquement des 
processus permettant de faciliter la création de site web sur l’intranet.  
 
Il a fallu par exemple faire une d ​ emande ​bien spécifique pour un s ​ erveur web​ afin 
d’exécuter ​l’application ​Django e ​ np ​ roduction​. 
 
Le site créé avec ​Django e ​ mbarque les outils du ​web 2.0​ notamment l’utilisation de 
websocket p ​ our une communication directe entre le client et le serveur. Regardons 
maintenant les packages majeurs utilisés pour la création de cette application. 
 
 
 
 
 
 
 
 
 
 
 
 

41
 8.1.7.1. Channels 
Channels e ​ st un packages P​ ython p
​ our ​Django​, il est disponible sur le site des 
packages python p ​ ypi.org​.  
 
Channels p ​ ermet d’introduire du code ​asynchrone d ​ ans le ​cœur ​synchrone de 
Django p
​ ermettant ainsi à Django de ​gérer e ​ n plus du protocole ​HTTP​, d’autres 
protocoles telle que le W ​ ebSocket ​qui nous intéresse pour ce p ​ rojet​. Voilà à quoi 
ressemble un échange de requête entre le client et le serveur sans Channels : 
 

 
 
Le ​WebSocket v ​ a nous permettre de créer des ​connections fixes ​entre le c​ lient 
qui navigue sur notre page web et le s ​ erveur ​qui va attendre les messages du clients ou 
lui en envoyer si un é ​ vénement ​se produit. Grâce à ce procédé, le site web sera en 
mesure d ​ ’envoyer ​et de r​ afraîchir ​en ​temps réel l​ es ​informations ​sur une page web ​sans 
que l’utilisateur n’ai à ​recharger s​ a p ​ age à​ la main.  
 
 
 
 
 
 
 
 

42
 Avec Channels, Django ressemble maintenant à :  
 

 
 
Nous présenterons plus tard les s​ tatuts ​des T
​ ests ​sur le site web qui s
​ ’actualise 
en ​temps réel​ sans rafraichissement de la part de l’utilisateur. 
 
 
 
 
 
 
 

43
 8.1.7.2. Celery 
Celery ​est aussi un packages P ​ ython d ​ isponible sur ​pypi.org​. C’est un 
gestionnaire ​de tâches a ​ synchrone​. Lorsque l’on construit une application Web, on a très 
vite besoin de gérer des tâches asynchrones qui ​sortent du périmètre du web​, c’est à dire 
lancer des p​ rocessus ​en a​ rrière-plan​ sur le serveur comme : 
- Uploader une image pendant que l’utilisateur continue sa vie 
- Envoyer une notification par e-mail 
- Relancer des Tests directement depuis le site web​ ! 
 
Pour le projet​ QA Machine​, ​Celery ​nous a permis de réaliser une page web nous 
permettant de relancer un ​Test ​en a ​ rrière-plan​ sur le s
​ erveur​. 
Pendant ce temps, l’utilisateur peut faire autre chose. 
 
Celery ​ici gère les t​ âches d
​ emandées et les places dans une 
queues d​ e tâches. Il exécutera tout seul une par une ou deux par 
deux suivant le paramétrage les tâches qu’il a reçu dans la queue. 
 
Celery ​est facile à mettre en place s ​ ’automatise ​très 
facilement, tout en fournissant des outils plus complexes permettant de réaliser des 
tâches beaucoup plus complexes. Nous parlerons de ​l’exécution d ​ es ​Tests ​par ​Celery​. 

8.1.7.3. Rest Framework 

 
Django Rest Framework​ est un outil très puissant permettant la réalisation d
​ ’API 
Web ​très facilement.  
 
Nous avons utilisé D ​ jango Rest 
Framework ​pour le “​Bridge​” entre la 
QA Machine​ et l’application ​ARTE​, cette 
dernière ​communique ​avec le s ​ erveur 
web ​de la QA Machine par une A ​ PI Rest 
pour évaluer, lancer des ​Tests ​et 
récupérer leurs r​ ésultats​. 
 
 
 
 
 
 
 
 
 
 
 

44
 8.1.8. Serveur Web (VM) 
Par l’intermédiaire des “​Flow​” de S
​ T​, nous avons pu faire une demande d’une 
machine virtuelle afin d’exécuter un serveur web pour notre projet. 
 
La M
​ achine Virtuelle​ utilise le système d’exploitation L​ inux Red Hat 7​, dispose de 
8 Go de Ram​ et un processeur ​2 Coeurs​. Elle dispose d’un ​nom de domaine​ pour la 
rendre accessible depuis n’importe quel navigateur de l'environnement S ​ T​. Elle est 
réservée aux membres de l’équipe ​ARCAD​. 

8.1.8.1. Services daemon pour Django 

Nous avons installé sur la ​VM8 ​des services permettant d​ ’exécuter l​ ’application 
Django e​ t de la r​ edémarrer automatiquement e ​ n cas de ​coupure d
​ us
​ erveur​. 
L’application redémarre automatiquement après le redémarrage de la M ​ achine Virtuel​. 

8.1.8.2. Nginx 
Nous avons décidé d’utiliser le ​serveur Web Nginx ​pour exécuter nos différentes 
applications Web.  
 
Pourquoi Nginx​ ? Il est s ​ imple ​et r​ apide à
​ mettre en place, ses fichiers de 
configuration sont faciles à comprendre. Il est plus facile de comprendre une 
configuration N ​ ginx c​ omplexe face à une configuration ​Apache c​ omplexe par exemple. 
 
Il a été préférable d’utiliser N
​ ginx ​pour sa s ​ implicité ​car nous sommes dans un 
contexte m​ icroélectronique ​avec des I​ngénieurs micro électroniciens​ n’ayant p ​ as 
forcément l​ e temps de faire une formation​ pour connaître les s ​ ubtilités ​d’un ​serveur 
Web​. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

8
VM: Virtual Machine = Machine Virtuelle.

45
 8.2. Fonctions 
8.2.1. Les Tests 
8.2.1.1. Structure 
Les ​Tests d​ e ​qualifications ​des différents ​Kits s​ uivent tous la m ​ ême structure​. 
Cela permet par exemple le ​partage d ​ ’une b​ ase d​ e ​Tests ​pour un autre K
​ it ​et ainsi 
simplifier et a​ ccélérer l​ a ​création d
​ e ​Tests a ​ u sein de ​l’équipe​. 
 
Voici la s
​ tructure ​de ​dossiers ​/ ​fichiers q ​ ue nous allons expliquer : 

 
 
description.info : 
 
Le Fichier ​description.info​ contient comme son nom l’indique, la ​description d ​ u t​ est​. Ce 
fichier est u
​ tilisé ​par le logiciel S
​ ynchronicity q
​ ui va le lire pour décrire le dossier 
versionné. 
La d
​ escription ​ne doit p ​ as dépasser 300 caractères​ afin d’être ​précis ​et ​concis s​ ur 
le fonctionnement de son Test. S ​ ynchronicity n
​ ’enregistre pas les caractères au-delà de 
300. 
 
 
 
 
 
 

46
manifest.yml : 
 
Le ​manifest.yml​ est au format ​Yaml​, un format de fichier proche des ​dictionnaire 
Python​ avec la notion de ​clé/valeur​. Ce ​type ​de ​fichier e ​ st très répandu en ​Python p ​ our 
stocker d ​ es d​ onnées​. Ce fichier contient les informations suivantes :  
 
- name :​ le nom du Test 
- description :​ le même contenu du fichier description.info 
- kit :​ le nom du Kit testé 
- owner :​ les nom et prénom du créateur du Test 
- backup ​: les nom et prénom de la personne en charge du Test en cas d’absence 
du créateur 
- state :​ l’état d’avancement de la création du Test 
 
INPUTS : 
 
Ce ​dossier ​contiendra tous les​ fichiers d'entrée du Kit​. Par exemple un 
programme faisant une addition de chiffres contenu dans plusieurs fichiers, on placera 
les fichiers contenant les chiffres dans le dossier I​ NPUTS ​pour en faire la r​ éférence à 
l’exécution​. 
 
GOLDEN_FILES : 
 
Les fichiers “​GOLDEN​”, sont les f​ ichiers de références​ lors de la c​ omparaison ​des 
résultats du ​Kit​. 
Par exemple, si mon programme génère un fichier : r​ esultat.txt​ contenant le 
texte : “​ ​OK​”​, et que je veux ​tester q ​ ue ce fichier r​ esultat.txt​ contient bien le texte “​ O ​ K​”​, je 
devrais mettre ce fichier dans le dossier ​GOLDEN_FILES ​pour que la ​QA Machine 
recherche e ​ t c​ ompare c​ e fichier quand ​l’exécution d ​ u Test est finie. 
 
OUTPUTS : 
 
Ce dossier contiendra les ​fichiers générés ​par le K ​ it ​lors de son ​exécution​. Par 
exemple, c’est dans ce dossier que devra être généré le fichier ​resultat.txt​ qui sera 
ensuite comparé avec le fichier ​resultat.txt​ dans le dossier G ​ OLDEN_FILES​. 
 
RUN : 
 
Ce dossier contient des fichiers​ .csh​ exécutable par la ​QA Machine​. L’utilisateur n’a 
pas à les toucher, ils sont g ​ énérés automatiquement​. 
On peut aussi trouver dans ce dossier un fichier nommé f​ ilter.yml​, ce fichier 
contient une ​liste de filtres​ avec e ​ xpression régulière ​qui permet de f​ iltrer ​les fichiers 
dans ​GOLDEN_FILES ​et O ​ UTPUTS p ​ our é
​ viter ​de ​comparer u ​ ne d
​ ate ​dans un fichier par 
exemple. 
 
 

47
 
PRJ_SETUP : 
 
Ce dossier contient les configurations qui permettent de charger un 
environnement spécifique à l’infrastructure ​ST​ pour l’exécution des Tests. 
 
Pour charger l​ ’environnement ​du T ​ est​, nous utilisons un utilitaire fourni par ​l’IT 
permettant de charger les P ​ roduits s​ pécifiés dans un certain fichier. Cet utilitaire est 
nommé “​prj​”. Grâce à cette commande, l​ ’environnement ​charge les ​produits d ​ e 
l’infrastructure ST e ​ n suivant une ​procédure standard ​que tout le monde utilise. 
Cette procédure nous permet d’exécuter un ​Test c​ omme si le ​Kit testé​ était en 
condition réelle ​pour le travail d’un ​Designer e ​ t donc au plus proche du c​ lient final​. 
 
Le dossier P ​ RJ_SETUP ​contient un fichier et plusieurs dossiers. Chaque dossier 
commence par “​TRUNK_CONFIG​” et contiennent les fichiers nécessaires à la 
configuration de l’environnement de T ​ est​. 
Dans les dossiers “​TRUNK_CONFIG​”, nous trouvons les fichiers : 
- “​.ucdprod​” 
 
C’est le fichier qui contient les produits à charger quand la commande “​prj​” est exécuté. 
Ce fichier se structure en colonne et ligne avec colonne 1 le nom d’un produit et colonne 
2, la version du produit, par exemple : 
PyCharm 2019.1.3 
gcc 8.2.0 
[ … ] 
Une fois que la commande “​prj​” a finit de charger l’environnement, l’utilisateur peut 
utiliser le logiciel PyCharm et gcc. 
 
- “​pre_prj_setup.csh​” 
 
Pendant l’exécution de la commande “​prj​”, cette dernière va exécuter le fichier 
“​pre_prj_setup.csh​” ​avant l​ e chargement de l’environnement. Ce fichier permet 
notamment de p ​ aramétrer ​certaines v ​ ariables d’environnement s​ i nécessaire pour le 
chargement de certains programmes. 
 
- “​post_prj_setup.csh​” 
 
Après ​le chargement de l’environnement pendant l’exécution de la commande “​prj​”, le 
fichier p
​ ost_prj_setup.csh​ va être exécuté. C’est ce fichier qui se chargera de lancer les 
commandes nécessaires pour l’exécutions du script​ run.csh q ​ ui est le coeur même de 
l’exécution du T ​ est​. 
 
- “​run.csh​” 
 
Ce fichier est p​ ersonnalisé ​par le c​ réateur ​du T ​ est​, c’est ce fichier qui doit e
​ xécuter ​les 
fonctionnalités v ​ oulues pour ​tester ​le ​Kit​. 

48
 
Le dossier P​ RJ_SETUP ​peut contenir plusieurs dossiers T
​ RUNK_CONFIG c​ orrespondant à 
plusieurs configurations​. Chaque ​configuration ​peut avoir ses propres fichiers I​ NPUTS e
​ t 
fichiers G
​ OLDEN_FILES​. 

8.2.1.2. Exécution 
Pour e​ xécuter ​un ​Test​, nous utilisons 2​ outils principaux​ de l​ ’infrastructure​ de ​ST​, à 
savoir : 
- LSF 
- prj 
 
Nous mettons à d ​ ispositions ​pour le c​ réateur ​du T
​ est ​un fichier​ run.csh​ qui devra 
contenir toute la l​ ogique d’exécutions​ des ​fonctionnalités t​ estées du ​Kit ​voulu.  
 
Une fois le fichier r​ un.csh​ bien développé, nous pouvons l​ ’exécuter​. Pour ce faire, nous 
n’allons pas exécuter ce script sur la machine actuelle de l’utilisateur car l’utilisateur a 
peut-être déjà paramétré un environnement qui n’est pas compatible avec son Test. 
 
Nous allons alors ​exécuter l​ e​ Test ​sur une autre machine en ​utilisant l​ ’outil ​LSF​. 
 

 
Grâce à L ​ SF​, le ​Test s​ era ​exécuté ​dans un environnement “​propre​”, sans paramétrage 
personnel de l’utilisateur qui pourrai venir p ​ arasiter ​l’exécution du T ​ est​. Cela permet de 
mettre en c​ ondition c​ omme si le Test était ​exécuté ​par un D ​ esigner q
​ ui n’a peut-être pas 
les mêmes paramètres personnels que l’utilisateur. 
 
A la f​ in d
​ e ​l’exécution d ​ u fichier r​ un.csh​, tous les ​fichiers g​ énérés par le ​Test s​ e 
retrouveront dans le dossier O ​ UTPUTS d ​ e la structure du T ​ est​. 
 
 
 

49
 

8.2.1.3. Evolution de l’interface 

Prototype :​  

 
 
V1.0 : 

 
 
 
 
 
 
 
 
 
 
 
 

50
V1.5 : 

 
 

51
V2.0 

52
V2.1 

 
Voir Annexe : Création d’un Test pour plus d’images de la version ​2.1 
   

53
 
8.2.1.4. Création d’un Test

Voire Annexe : Création d’un Test

8.2.2. Automatisation des Tests 

8.2.2.1. Crontab 

Tous les matins à ​0h10​, un script ​C-Shell ​est exécuté grâce au logiciel “​Crontab​” qui
permet l’exécution automatique de script à une heure précise.

Le script exécuté par ​Crontab ​va suivre un nombre d’étapes spécifié permettant :
1. La détection des ​nouveaux Produits ​apparue sur l’intranet de ST
2. La récupération des Tests sur ​Synchronicity
3. La mise à jour des ​Configurations d ​ es ​Tests ​suivant les nouveaux ​Produit
4. La création des ​exécutables ​des ​Tests
5. L’exécution ​des Tests
6. L’envoie de ​rapports ​par ​e-mail​.

8.2.2.2. Scan des nouveaux Produits 

Les “​Produits​” au sein de ​ST ​peuvent être des ​logiciels​, des ​librairies​, des ​kits​,
des ​Design Kits ​... Tout ce qui se rapporte à une ​fonctionnalité ​avec un ​exécutable​.

Chaque ​Produit ​est renseigné grâce à un logiciel nommé “​UPTPlus​”, qui permet de
désigner une structure spécifique pour chaques ​Produits​, on appelle ces Produits les
produits unicad​.

Une fois un ​Produit ​renseigné sur le logiciel ​UPTPlus​, ce dernier va écrire dans un
fichier “ucdprod” :
- Le ​nom ​du Produit
- Sa ​version
- Son ​emplacement ​sur les disques
- Sa ​date ​d’apparition

Grâce à ces informations, tous les matins nous pouvons ​analyser ​ces fichiers
“​ucdprod​” et déterminer les nouveaux ​Produits ​apparus la veille ainsi que les ​Produits
manquants.

Les ​nouveaux Produits ​sont enregistrés dans la base de données du ​site web​. Ces
nouveaux ​Produits ​pourront alors être définis dans les ​configurations ​des ​Tests​, si ces
Produit ​sont définis comme “​Dynamic​”.

54
 8.2.2.3. Récupération des nouveaux Tests 
Les ​Tests sauvegardés ​avec le logiciel ​Synchronicity ​sont récupérés grâce à la
commande “​populate​” de ce dernier.

Tous les ​Tests ​sont rapatriés dans une ​zone spécifique ​pour que la ​Machine
Virtuelle ​qui maintient le ​site web​, puisse les l​ ires​.

8.2.2.4. Scan des Tests 

L’arborescence ​de chaques ​Tests ​est ​analysée ​pour déterminer les ​nouvelles
configurations ​par rapport aux ​nouveaux Produits ​détectés.

Chaque ​Test ​détient un ou plusieurs dossiers ​TRUNK_CONFIG ​contenant une

configuration​, un ​Test ​peut avoir plusieurs configurations.

Tous les fichiers “​.ucdprod​” dans les dossiers T​ RUNK_CONFIG ​sont analysés pour
déterminer les Produits “​Dynamic​” et “​Static​”. Un dossiers ​LATEST_CONFIG ​est créé pour
chaque dossier ​TRUNK_CONFIG​, contenant un fichier ​.ucdprod​ avec les Produits
“​Dynamic​” mis à jour suivant les ​nouveaux Produits​ détectés.

8.2.2.5. Création des exécutables 

Les ​Tests ​ayant maintenant de ​nouvelles configurations ​et leurs chemins d’accès
ayant été modifiés après l’import depuis Synchronicity, il est nécessaire de ​régénérer ​leurs
exécutables​ pour pointer sur les bonnes configurations.

8.2.2.6. Exécutions des Tests 

Les Tests sont ensuite tous ​exécutés 30 par 30 ​(​pour l’instant​). Les ​Tests ​ne
peuvent pas tous s’exécuter en même temps, (il y en a plus de 100) car certains ​Tests
utilisent des ​Licences ​de ​logiciels ​peu nombreux. Il ne faut ​pas bloquer ​l’accès à ces
logiciels ​pendant que tous les ​Tests ​sont ​exécutés​.

L’exécutions de la totalité des Tests peut prendre plusieurs heures.

8.2.2.7. Comparaison 
Pendant l’exécutions des Tests, si un ​Test ​se ​termine​, un ​script ​de ​comparaison
est ​exécuté ​pour déterminer le ​Statut d
​ u Test.

Le statut sera déterminé​ :

- “​Missing​” si il ​manque ​un fichier dans le dossier ​OUTPUTS
- “​Mismatch​” si il y a une ​différence ​entre le ​fichiers ​dans ​OUTPUTS ​et
GOLDEN_FILES
- “​Failed​” si ​l’exécution ​d’un des logiciels du Test se ​termine ​avec une ​erreur
- “​Pass​” si toutes les conditions précédentes ne sont pas remplies.

55
 8.2.2.8. Envoi de rapports par e-mail 

Une fois que ​tous ​les ​Tests o

​ nt été ​exécutés​, si un des Tests d’un ​utilisateurs ​n’est
pas de statut “​Pass​”, un ​rapport ​par ​e-mail​ est envoyé avec le ​statut ​de chacun des ​Tests
lui appartenant et un lien permettant d’accéder directement aux ​détails ​du Test.

9. Problèmes rencontrés  
9.1. Infrastructure ST 
L’infrastructure de ​ST ​a été problématique car l’installation de logiciel tiers ou de
packages ​Python ​est contrôlée ou impossible. Il a fallu refaire à la main certaines parties qui
auraient pu simplement être téléchargée et installée de façon “normale”.

La demande et la réalisation de ​Machine Virtuelle​ est complexe et très longue, il

aura fallu un peu plus d’un an pour réceptionner la Machine Virtuelle qui nous permet
maintenant de mettre en ​production ​nos différentes a
​ pplications web​.

9.2. Réticence au changement 

La moyenne d’âge de ​ST ​est élevée et pendant une grande période ST n'embauchait
plus de jeune recrues. Avec le temps, les équipes sont restées sans nouvelles méthodes de
travail venant d’un nouvel œil.

J’ai donc été confronté à une ​réticence au changement​, où les personnes de

l’équipe n’étaient pas convaincues de l'efficacité de la ​QA Machine​, ne voulaient
simplement pas l'utiliser car elle changeait leur manière de valider leur Test et de travailler.

Pour résoudre ce problème, j’ai accompagné mes collègues dans l’adaptation et la

réalisation de leur Test. Je les ai écoutés quand ils me proposaient de nouvelles
fonctionnalités, je leur ai montré qu’ils appartenaient à ce projet, qu’ils étaient importants
dans la réalisation de ce dernier.

Avec le temps, presque la totalité des collègues utilisent la​ QA Machine​ pour réaliser
leur ​Tests ​et certains proposent encore des​ améliorations ou de nouvelles fonctionnalités​.

56
10. Conclusion 
Bilan professionnel 
 
Grâce à STMicroelectronics, j’ai appris à vivre et évoluer dans une grande 
entreprise. J’ai pu mettre en application mes connaissances acquises durant mes études 
et ainsi appris à appliquer dans environnement n'étant pas orienté développement de 
logiciel à 100%.  
 
J’ai donc appris à m’adapter à l'environnement microélectronique dans lequel je 
me trouvais.  
 
Mon passage dans l’équipe ARCAD m’a permis de gérer un projet de A à Z et d’en 
voir tous les aspects et problématiques. J’ai eu l’occasion de donner des formations à 
mes collègues sur les Framework Kraken et Django en Python ainsi que sur la gestion de 
Machine Virtuelle. 
 
Je compte maintenant sur mes collègues pour faire persister ma création, la 
maintenir et l’améliorer si nécessaire. 
 
Bilan personnel 
 
Cette alternance m’a permis d’avoir plus confiance en moi et d’améliorer ma 
capacité de persuasion et de motivation envers des Ingénieurs expert dans leur domaine. 
J’ai par exemple réussi à les convaincre d’utiliser de nouvelles méthodes de travail pour 
le développement d’applications. 
 
Durant ces 3 dernière années, j’ai conforté ma manière d’organiser mon travail. Je 
voyageais beaucoup entre Grenoble et Lyon, en plus de gérer mon travail pour l’école et 
l’entreprise. 
 
Ce passage chez STMicroelectronics m’a permis d’acquérir une expérience 
majeure pour la suite de mon parcours professionnel. 
 
Je tiens principalement à remercier tous mes collègues de l’équipe ​ARCAD ​et de 
l’équipe ​Support & Productivity Tool​ pour m’avoir transmis un savoir exceptionnel. 
 
 
 
 
 

57
11. Bibliographie et webographie 

Synchronicity : 

https://ifwe.3ds.com/fr/high-tech/high-performance-semiconductor/semiconductor-co
llaborative-design

Icons made by :

Icongeek26, Eucalyp, geotatah, Pixelmeetup, Smashicons, monkik, Twitter, Roundicons, 

srip, Eucalyp, Nhor Phai, Freepik from www.flaticon.com is licensed by CC 3.0 BY.

Schéma et Layout partie “​6.3.2.4​”: 

https://mkprojects.wordpress.com/category/electrical-engineering/analog-microelectr
onics/

Electrical Rule Check :

https://www.edn.com/design/eda-design/4018778/Programmable-electrical-rule-chec
king 

Programmation : 

https://pypi.org/ 
https://www.python.org/ 
https://www.anaconda.com/ 
https://fr.wikipedia.org/wiki/Qt 
http://nils.hamerlinck.fr/blog/2015/03/27/celery-django/ 
https://www.django-rest-framework.org 

STMicroelectronics : 

https://fr.wikipedia.org/wiki/STMicroelectronics 
https://www.virtuoso-software.com/ 
https://fr.wikipedia.org/wiki/Conception_de_circuits_int%C3%A9gr%C3%A9s 
https://fr.wikipedia.org/wiki/Silice 

Livre : 

Linux : précis et concis​, ​2005​, par ​Daniel J. Barret 

 
 

58
12. Annexes 
- Qa Machine Specs octobre 2016 
- Création d’un Test 
- Site Web 
 

59