RESTRICTED

U-TEST CONF
➢ Configuration applicable est définie par l'expression des besoins, rédigée par le client, dans laquelle il
spécifie la configuration de train qu'il souhaite.

➢ Jigsaw: Used to Build connections between data and create configuration files.
➢ U-TEST: Allows interaction between real electronics and simulated parts of a train.
➢ ControlBuild: Design and validate the control software for Real-Time Embedded Systems.
➢ Simulatio: Simulator for low voltage electric diagrams.
➢ SQLiteStudio: is a high quality, visual, open-source tool to create, design, and edit database files.
➢ E3S: CAD software in electric schematics, used for the display of Simulatio results.
➢ StartLabo : a deployment tool

➢ CoSim: Validates equipment interfaces in a virtual environment.

➢ TestBench (TB): Validates the real TCMS, using a configuration based on CoSim.
➢ TrainLab (TL): Simulates a train with real equipment, based on TB configuration.

➢ Real-Time Controller (RTC): system used to execute real-time tasks required for train simulations: running
the software and handling communications between different parts of the system, including the TCMS (Train
Control and Monitoring System), simulated equipment, and real hardware.

➢ Train Network: connects servers and MPUs and DDUs...

➢ CITADIS: tramway

➢ AVELIA: train

➢ AVELIA and CITADIS use different architectures because of differences in the type of equipment, system
design, and project-specific configurations (AVELIA = FCS format, CITADIS = UserCode formats)

➢ The archived configuration should include both the input data (e.g., databases, schematics, ICDs) and
output data (e.g., generated configuration files, final release notes)

➢ Clustering optimization allows U-TEST to distribute processing tasks across multiple RTC servers, preventing
overload during configuration deployment.

➢ S’il y a une évolution de voiture, on change la configuration et SPP.

➢ VS: virtual simulation

➢ TO UPDATE EQUIPEMENT :
o IN JIGSAW: go to sw_instances, in the id_sw choose the EQT.tgz with the latest version, then copy
this id_sw to all instances of the eqt
o In hw_instance go to column DATA then go to id_config_train: if id=1 it’s activated on HW and
should be NULL on sw_instance

➢ Integrer SPP et ICD:

o On ICD_organ_list:
▪ Filter par colonne id_ICD, filter by numb 7 to get the recent added
▪ Copy ALIAS, ALIAS_NETWORK from the new ICD
▪ If ALIAS in sw_instance is null, then null on ICD_organlist
▪ If ALIAS in hw_instance is null, then remove from ICD_organlist
▪ If real eqt =1 on hw_instance, then make it =0 in id_config_train on sw_instance and
icd_organlist
 RESTRICTED

▪ Finally change config_train and increment one (change id_spp and id_icd If ALIAS in
sw_instance is null then null on ICD_organlist
➢ Workspace:
o Create folder
o UTEST:
o JIGSAW:

➢ Configuration Name :
[Projetname]_ [(STR)or (BSL)x. y] _ [trainConf NBcars KTcarposition BARcarposition] _ [wrkplce type] _ [ID
incrmnt config] _ [incrmnt modifs]
kt car: voiture clé, is the one that has the 2 lignes TRAIN LINE opposées

1. Generation Steps :
➢ To identify configuration evolution:
o applicable configuration: from client (name xx_old to delete later)
o release note by CoSim or TB concerns TB or TL respectively
For AVELIA:
o Directory AVELIA on teams
o CoSims
o Open excel xxx_Configurations (yellow=new) (white: was done last conf)
o Then directory AVELIA, choose release notes of TB latest version
For CITADIS:
o Applicable configuration sent by TSE (purple = don’t consider in the next
configuration)
o Release notes not applicable for CITADIS
➢ To collect new input data:
o Data needed: SPS project; ICD master; UserCodes (C++); MBS (connects UserCodes); SW;
HW data; Previous Database; TCMS SW UC(used on coSim); AteConf (save in folders named
same)
➢ Prep Data:
o On JIGSAW (old conf) import old conf in utest rt, importing the collected data to the database,
then updating the necessary tables, delete the xx_old)
➢ Weaving and generation of the configuration in Jigsaw: (WEAVE = LINK)
o Create automatically the links between the three essential parts of the train (BT, TCMS and the
equipment) from the database prepared previously. And generate the configuration files: UC;
MemoryVariable; EACB; Hard; ICD.ate; S1003
➢ Manual changes:
o The last step before generating the executable code.
o The bench is defined by the ateconf file.
➢ Configuration comparison:
o Changes have been considered, no loss of information.
➢ Generation of the configuration in U-test:
o Generate RTC files (. gc) = code, called “bases” uploaded and executed in the RTC.

2. Deployment: (StartLabo)

Run the executable code generated by U-TEST on the RTCs, ensure that real equipment start correctly and the
connection between all software and equipment is done.

➢ Steps:
o Update paths: files in starlabo
o Update Simulatio request
o Remote access to RTCs (MobaXterm): allows remote access to RTCs using their IP address
 RESTRICTED

o launch deployment (startlabo)

o Software launch verification (Simulatio / CB/ E3S)
o Connect to RTC Server: connection to an existing RTC Server where conf is deployed allows to
perform supervision.
o Train preparation: simulation of the train supply by the prepared line simulation display with e3s
and power button on
o Hardware power supply
o Connect to CB Server: connect CB to MPU for monitoring
o Start functional test: run test scenarios after archiving and delivery
▪ TCMS FCS UC allows communication TCMS CB and UCs under UTEST. (Case of AVELIA)
• CITADIS deployment only using U-Test
3. Configuration archiving
4. Configuration delivery
 RESTRICTED

1. Create project and folders (Purpose: Set up necessary project and file structure)

o Tool: File Explorer (To create and organize project and configuration folders)

2. Prepare MPU software (Purpose: Install and configure MPU software for the correct test environment)

o Tool: Unzip Utility, StartLabo (To extract the MPU.zip file and configure the MPU software)

3. Update simulation files (Purpose: Configure simulation request files for the specific test setup)

o Tool: Text Editor (e.g., Notepad++) (To edit and rename simulation request files for Simulatio)

4. Access RTCs remotely (Purpose: Clean old configurations and prepare RTCs for new deployment)

o Tool: MobaXterm (To remotely access RTCs, clean up previous configurations, and prepare them)

5. Launch the deployment (Purpose: Start the test environment for embedded or simulated tests)

o Tool: StartLabo (To deploy the configuration and launch tests for embedded or simulated
environments) bench on and SupervisionPC StartLabo

6. Verify software launch (Purpose: Ensure all necessary software components are running properly)

o Tool: U-TEST MMI, Simulatio (To manually check if the software components are running)

7. Connect to RTC Server (Purpose: Establish a connection for monitoring and supervision)

o Tool: StartLabo, RTC Connection Interface (To connect to the RTC server for monitoring)

8. Simulate train preparation (Purpose: Simulate the power supply to the train systems in the test environment)

o Tool: Simulatio PC, E3S Display (To simulate the train systems and monitor the schematic)

9. Check hardware power (Purpose: Ensure all physical equipment is powered)

o Tool: Visual inspection (To check if the bench equipment is powered)

10. Connect to CB Server (Purpose: Monitor real MPU for hardware test results)

o Tool: Multi Putty (To connect to MPU and verify the equipment network status)

11. Verify connections (Purpose: Ensure communication between all systems and perform stability tests)

o Tool: Simulatio, U-TEST, MPU (To verify communication among systems and run endurance tests)

11. Run functional tests (Purpose: Start running the functional tests and monitor system behavior)

o Tool: Test Program (To execute the functional tests and analyse system responses
 RESTRICTED

U-TEST:
• U-test project will be deployed on each RTC computers
• RTC are connected to the VS
• PC supervisor: connected to the VS
• Interface between RTC and the train network is done by RPServer(s)
• Simulatio and U-test data exchanges are made through a middlware
• Clustering optimization to optimize memory-variables management
• Scheduling AND Dataset

Formation TL
➢ Les données d’entrées :
o Quels sont les données d’entrée livrées par Train control :
▪ TCMS SW, modèles des équipements, ICD
o Quels sont les données d’entrée livrées par S&A :
▪ Le schéma SPS
o Quels sont les données d’entrée livrées par CCAMY :
▪ Le projet simulation BT
o Quels sont les données d’entrée réalisées au TrainLab :
▪ Fichier MBS, AteConf
o Quels sont les données d’entrée livrées par le client :
▪ La conf applicable

➢ SPS (schéma complet du train pour visualiser) code lecture / Code commande (simulation)
➢ La configuration applicable est définie par l'expression des besoins, rédigée par le client, dans laquelle il
spécifie la configuration de train qu'il souhaite.
➢ Quel outil permet d’importer les données d’entrées dans la BDD : Jigsaw
➢ MBS : C’est pour faire des liens entre deux Usercodes
➢ Jigsaw : Importer les données d’entrée, Tisser, Générer les fichiers de la configuration utilisables par Utest
➢ Utest : Génération de la conf sous forme d’un code exécutable sur un RTC, Supervision
➢ Mobaxterm : il permet d’accéder à distance à un serveur (RTC) grâce à une session SSH
➢ Startlabo : exécute pour déployer la conf sur le banc approprié
➢ E3S : la visualisation du schéma
➢ Simulatio : simulation du schéma
➢ MultiPutty : Il permet de connecter le MPU réel à l’application CB via le CB server.