CAPET informatique externe 2024, épreuve 1, option ingénierie informatiqueSujet et rapport du jury
Capet externe section sciences industrielles de l'ingénieur option ingénierie informatique - Sujet de la première épreuve écrite de la session 2024
- Modélisation UML (cas d'utilisation, déploiement)
- Programmation orientée objet en C++
- Réseaux et protocole Modbus/TCP-IP
- Bases de données relationnelles et SQL
Téléchargements
- Corrigé : pas encore disponible
Présentation du sujet
Simulateur de voilier : modélisation UML, physique embarquée, réseau et base de donnéesAfficher ou masquer la section
Présentation du sujet
L'épreuve écrite disciplinaire porte sur un simulateur de dériveur destiné à la formation des skippers. Le sujet comporte cinq parties indépendantes : modélisation UML du système, simulation de la poussée d'Archimède dans le moteur de jeu vidéo, implémentation orientée objet de la polaire de vitesse, communication Modbus/IP avec l'automate, puis mise en exploitation en réseau avec une base de données relationnelle.
- 1Partie 1 : contexte et modélisation UMLDiagrammes de cas d'utilisation et de déploiement, capteurs de position et puissance propulsive de la bôme.
- 2Partie 2 : poussée d'Archimède dans le moteur de jeu vidéoAlgorithme de gestion d'objets 3D maillés pour déterminer la partie immergée du bateau.
- 3Partie 3 : polaire de vitesse en programmation orientée objetInterpolation bilinéaire de la vitesse et codage d'une classe C++.
- 4Partie 4 : communication Modbus/IPÉchanges client/serveur entre le logiciel et l'automate, analyse de trames TCP/IP et mécanisme de MUTEX.
- 5Partie 5 : mise en exploitation en réseauArchitecture réseau, plan d'adressage IP, base de données relationnelle MySQL et requêtes SQL.
Ce qu'a observé le jury
6 erreurs relevéesModélisation UML mal maîtrisée · Maillage d'objets 3D peu formalisé · Erreurs de calcul en interpolation bilinéaireAfficher ou masquer la section
Ce qu'a observé le jury
6 erreurs relevéesLe sujet, construit autour d'un simulateur de voilier, a été largement abordé par les candidats sur ses premières parties, mais la proportion de candidats traitant correctement les questions diminue nettement sur les parties réseau et base de données. Le jury relève des lacunes récurrentes sur la modélisation UML, la programmation orientée objet et les notions de réseau.
Les erreurs les plus sanctionnées
- 1Modélisation UML mal maîtriséePartie 1
Le jury constate un manque de connaissances sur les relations UML « extend » et « héritage », ainsi que des réponses incohérentes sur les valeurs de capteurs de position.
« Le jury remarque un manque de connaissances sur l’aspect modélisation UML »
- 2Maillage d'objets 3D peu formaliséPartie 2
Peu de candidats parviennent à formaliser correctement le maillage des objets et le calcul du volume d'eau déplacé, ce qui empêche de proposer un algorithme complet.
« Peu de candidats formalisent correctement, à partir d’exemples, le maillage des objets »
- 3Erreurs de calcul en interpolation bilinéairePartie 3
La moitié des candidats commet des erreurs de calcul sur l'interpolation bilinéaire de la vitesse du bateau.
« 50% de candidats font des erreurs de calcul sur la partie d’interpolation bilinéaire »
- 4Notion de thread et de MUTEX mal connuePartie 4
La moitié des candidats ne connaît pas le rôle d'un thread dans une relation client/serveur, ni la notion de MUTEX.
« 50% des candidats ne connaissent pas le rôle d’un thread dans la relation client/serveur »
- 5Table de routage rarement maîtriséePartie 5
Très peu de candidats parviennent à proposer avec justesse une table de routage pour l'architecture réseau demandée.
« Seulement 4% des candidats proposent avec justesse une table de routage »
- 6Contrainte référentielle en base de données peu connuePartie 5
La notion de contrainte référentielle entre tables d'une base de données relationnelle reste peu maîtrisée par les candidats.
« La notion de « contrainte référentielle » entre tables est peu connue des candidats. »
Ce qui a été bien réussi
- La partie 1, sur la modélisation UML et le contexte du système, a été abordée par 100 % des candidats.
- 65 % des candidats proposent une déclaration de classe s'approchant de l'attendu en programmation orientée objet.
Conseils du jury
- Prendre le temps, dès la réception du sujet, d'en faire une lecture rapide mais complète pour localiser les éléments de réponse fournis.
- Consolider les bases de la modélisation UML (relations extend et héritage) avant l'épreuve.
- Revoir les fondamentaux des réseaux (adressage IP, routage) et des bases de données relationnelles (jointures, contraintes référentielles).
- Veiller à la cohérence des réponses vis-à-vis des questions posées et soigner l'orthographe et la lisibilité de la copie.
Synthèse rédigée par WikiPrépa à partir du rapport officiel du jury (à télécharger en PDF). Les citations sont extraites du rapport.
Description
Sujet officiel CAPET externe en informatique, session 2024.
Ces sujets peuvent vous intéresser
Pas encore de corrigé pour ce sujet : voici des sujets proches corrigés.
Lecture du sujet en ligne
L'énoncé complet, avec les formules et les figures, sans ouvrir le PDF.Afficher ou masquer la section
Lecture du sujet en ligne
CONCOURS EXTERNE ET CAFEP CORRESPONDANT ET TROISIEME CONCOURS
INFORMATION AUX CANDIDATS
- -Concours externe du CAPET de l'enseignement public :

- -Concours externe du CAFEP/CAPET de l'enseignement privé :

- -Troisième concours externe du CAPET de l'enseignement public :

DOCUMENTS :
- -DOCUMENTS TECHNIQUES :
DT1 - Statistiques station météo
DT2 - Documentation Vector3 Unity 3D
DT3 - Modbus over TCP/IP
DT4 - Protocoles usuels
Documents relatifs au support de l'étude - -DOCUMENTS RÉPONSES : DR 11, 37, 44, 45, 46
Documents à compléter et à rendre par le candidat
SIMULATEUR DE VOILIER



Tous les documents réponses, complétés ou non, sont à rendre avec les copies.
Partie 1 : Présentation du système et Impact socio-économique
- 1.1.Comparaison entre l'utilisation d'un simulateur et une école de voilier en bord de mer
- Q1. En considérant que les conditions idéales pour l'enseignement de la voile sont un vent inférieur à 56km.
h^(− 1) et une navigation de jour. Utiliser le document DT1 pour proposer un comparatif entre les deux solutions. Conclure sur l'intérêt de ce simulateur.
1.2.Modélisation du système


- Q2. Expliciter la relation entre les cas d'utilisation « Naviguer au vent » et « Naviguer au moteur ».
- Q3. Expliciter la relation entre les acteurs «Skipper à terre ou formateur» et « Skipper »

- Q4.Préciser les supports physiques associés aux relations entre l'armoire de puissance et les autres composants du diagramme et préciser le nombre de ces composants.
1.3. Partie opérative

| 1 vérin hydraulique linéaire pour la commande du tangage | Sans référence |
| 2 vérins rotatifs hydrauliques pour le roulis et le retour d'effort sur la bôme | Sans référence |
| 1 machine asynchrone pour la commande de l'axe de lacet |
|
| 2 centrales hydrauliques équipées de 4 vannes proportionnelles |
|
| 1 variateur de vitesse Leroy Somer | UMV 4301 2.5 T |
| 1 automate programmable | M340 |
| 1 interface graphique | HMI STU 855 |
- Q5. Lister les différences entre les mouvements possibles du simulateur et les mouvements réels d'un voilier ? Préciser les limites de ce simulateur.
L3 correspond à la longueur du vérin et varie en fonction de la sortie de sa tige.


- Q6. Exprimer l'angle
α de la Figure 5 en fonction de L1, L2 et L3 grâce au théorème d'Al-Kashi ; - Q7. Calculer l'amplitude maximum de
α entre les deux positions extrêmes du vérin.

Q 10. Calculer le plus petit angle mesurable sur l'axe du roulis. Préciser si cet angle est suffisant pour cette application.
- -Commander_le_bateau() ;
- -Manœuvrer la manette des gaz s'il n'y a pas de vent ou dans une situation délicate ;
- -Tirer sur l'écoute pour manœuvrer la voile ;
- -Afficher I'IHM (Interface Homme Machine) ;
- -Manœuvrer le Safran pour donner un cap ;
et tourne jusqu'à atteindre la position angulaire TWA-180. La différence entre TWA-180 et la position réelle de la bôme est stockée dans le registre cons-difbotwa.


L'asservissement du vérin rotatif du mât (déplaçant la bôme) est réglé « mou » de façon à permettre au skipper de tirer sur l'écoute pour écarter la bôme de sa position d'équilibre. Le skipper crée ainsi une erreur de position.
- -Vent venant de l'arrière du bateau, navigation « au large » : le maximum de puissance est obtenu quand |cons-difbotwa| est de 90° (cf. Figure 8).
- -Vent venant de l'avant du bateau, navigation « au près » : le maximum de puissance est obtenu si |cons-difbotwa| est de 180° (la bôme est alignée sur 180°) ;


- Q12. Navigation « au large » : Proposer une expression du ratio décrit Figure 9 en fonction de cons-difbotwa. Cette expression fera intervenir une fonction sinusoïdale.
- Q13. Navigation « au près » : Proposer une expression du ratio décrit Figure 10 en fonction de cons-difbotwa. Cette expression fera intervenir une fonction sinusoïdale.
- Q14. Proposer une explication sur la signification des traits pointillés des courbes Figure 9 et Figure 10.
- Q15. Que signifie « pom » dans « pom lacet ». Décrire l'impact de ce type de capteur sur la mise en marche du système vis-à-vis d'un codeur absolu ?
Partie 2 : Poussée d'Archimède
2.1. Objets maillés
- -La mer, un objet maillé plat (sans vague ici) ;
- -Le fond marin, un objet maillé plat également ;
- -Le bateau, qui en première approche, est un cube.

Vector3[] vertices = new Vector3[4]
{
new Vector3(0, 0, 0),
new Vector3(width, 0, 0),
new Vector3(0, height, 0),
new Vector3(width, height, 0)
};

int[] tris = new int[6]
{
0, 3, 1, // lower right triangle
0, 2, 3 // upper left triangle
};

- Q19. Sur la base des exemples présentés ci-dessus proposer la création des sommets d'un cube utilisant les variables : hauteur height, largeur width et profondeur depth.
- Q20. Sur la base des exemples présentés ci-dessus proposer la création des faces du cube utilisant les même variables ( height, width et depth ).
2.2. Calcul du volume sous l'eau

Étude de cas, le point
On ajoute un point
La documentation de la classe Vector3 est dans DT2, le calcul permettant de placer le point
Hypothèse :
- Q21. Proposer la ligne de code permettant de créer le Vector3 LH représentant le vecteur
LH^(→−) .
- Q22. Proposer la ligne de code permettant de calculer le ratio de la distance entre L et J vis-à-vis de LH.
- Q23. Proposer la ligne de code permettant de multiplier le Vector3 LH par le ratio et créer le Vector3 LJ_H représentant le vecteur
LJ_H^(→−) - Q24. Proposer la ligne de code permettant de créer le Vector3 J_H contenant les coordonnées du point
J_H . - Q25. Proposer un algorithme permettant de générer une liste de triangles sous l'eau conformément à la Figure 14 (on pourra proposer une solution en pseudo-code, python, JAVA, C/C++ ou C#).
Cet algorithme doit prendre en entrée les tableaux de triangles et sommets comme définis dans Figure 12 et Figure 13. En sortie l'algorithme doit créer deux nouveaux tableaux, sommets et triangles, issus des découpages tel que décrit Figure 14.
Une méthode « distanceToWater(Vector3 vertice) : float » existe pour obtenir la hauteur algébrique d'un sommet par rapport à l'eau. - Q26. Lister les différents éléments restant à simuler et émettre des pistes pour le faire. Conclure sur la validité de l'approche.
Partie 3 : Polaire de vitesse
3.1. Polaire de vitesse

Pour un vent de 16 nœuds, un angle de vent de 125° le bateau (class40) se déplace au maximum à 12,4 nœuds. Le maximum est obtenu avec une voile parfaitement réglée.
- Q28. Proposer une équation exprimant
V_1 en fonction deV_(11), V_(12), tws, tws_1 ettws_2 . Appliquer cette formule pour un vent de 12 nœuds et un angle à 85°.

- Q29. Proposer L'équation de
V_2 en fonction deV_(21), V_(22) , tws, tws1 et tws2. Puis en utilisantV_1 etV_2 proposer l'équation de V. Calculer le résultat pour un vent de 12 nœuds et un angle de 61°.

3.2. Utilisation de la polaire de vitesse

class Polaire: public QObject
{
private:
QVector<ElemPolaire*> datas;
ElemPolaire* getElemPolaire(int twa);
void addTwa(int twa);
void addWindSpeed(int twa, int windSpeed, double boatSpeed);
Polaire(){}
public:
virtual ~Polaire(){}
Polaire(QString polFile); // ouvrir un fichier pol
double getMaxSpeed(double twa, double windSpeed);
double getMaxGite(double twa, double windSpeed);
QString toString();
};
- -Charger les vitesses par extraction des données du fichier texte ascii « .pol » dans des objets contenant les informations TWA, TWS et vitesse du bateau.
- -Calculer la vitesse du bateau pour toutes valeurs TWA et TWS par bi-linéarisation.
Q 31. Proposer une implémentation en C++ possible de la méthode toString() de la classe Polaire.
Hypothèses : la classe QVector a un accesseur par [indice] et la classe QString accepte la concaténation par l'opérateur +.
Partie 4 : Communication
4.1.Protocole Modbus
| Registre | Nb reg | Nom du registre | Description | Type |
| 40001 | 2 | lect-roulis | position roulis (deg), RAB → PO | Float |
| 40003 | 2 | lect-tangage | position tangage (deg), RAB → PO | Float |
| 40005 | 2 | lect-bome | position bome (deg), RAB → PO | Float |
| 40007 | 2 | lect-vitazimut | vitesse azimut (rad/s), RAB → PO | Float |
| 40009 | 2 | reserve | Pour utilisation future, RAB → PO | Float |
| 40011 | 2 | cons-etat |
|
Float |
| 40013 | 2 | cons-gouv | -1/1 position gouvernail,
|
Float |
| 40015 | 2 | cons-roulis | consigne de position roulis (deg),
|
Float |
| 40017 | 2 | cons-tangage | consigne de position tangage (deg), PO → RAB | Float |
| 40019 | 2 | cons-difbotwa | diff angle réel bôme réf. bateau et lect-bome,
|
Float |
| 40021 | 2 | cons-vitazimut | consigne de vitesse azimut (+/-rad/s) | Float |
| 40023 | 2 | cons-acc | consigne de l'accélération (-1 a 1), PO → RAB | Float |
| 40025 | 2 | cons-tws | True Wind Speed | Float |
| 40027 | 2 | cons-swa | consigne de la direction du vent System Wind Angle | Float |
| 40029 | 2 | cons-hautvague | consigne de hauteur de vague (m) | Float |
| 40031 | 2 | cons-vitvague | consigne vitesse de vague (m/s) | Float |
| 40033 | 2 | cons-intervague | consigne de distance inter vagues (m inter crêtes) | Float |
- Q33. Quel est le débit applicatif utile utilisé ? Quel en est l'impact vis-à-vis des performances d'un échange WIFI 802.11 b/g/n.
- Q34. Dans le cas où, en exploitation, il y aurait plusieurs simulateurs proches, les postes RollABoat étant reliés en WIFI. Quelles seraient les précautions à prendre en compte pour mettre en œuvre les liaisons ?
- Q35. Valider tous les octets de la trame requête. Voir DT3.
- Q36. Proposer une trame de réponse possible pour des données nulles.
| 0000 | 00 | d0 | c9 | 17 | 09 | 61 | 00 | 0f | b0 | 71 | c4 | c1 | 08 | 00 | 45 | 00 | a | E. | |
| 0010 | 00 | 40 | 00 | 00 | 40 | 00 | 40 | 06 | 00 | 00 | ac | 10 | 26 | 01 | ac | 10 | . © | @ . C | |
| 0020 | 26 | 03 | d5 | 5d | 01 | f6 | 58 | 43 | 6c | f7 | c6 | eb | 5b | 9d | 80 | 18 | ] | XCl | [ . . . |
| 0030 | 18 | e9 | 83 | a1 | 00 | 00 | 01 | 01 | 08 | 0a | 1e | d8 | c6 | b4 | 1e | d8 | |||
| 0040 | c6 | 19 | 00 | 41 | 00 | 00 | 00 | 06 | ff | 03 | 00 | 0c | 00 | 02 |
| 0000 | 00 | 0f | b0 | 71 | c4 | c1 | 00 | d0 | c9 | 17 | 09 | 61 | 08 | 00 | 45 | 00 | q | a | E. | |
| 0010 | 00 | 41 | 00 | 00 | 40 | 00 | 40 | 06 | 00 | 00 | ac | 10 | 26 | 03 | ac | 10 | [email protected] | |||
| 0020 | 26 | 01 | 01 | f6 | d5 | 5d | c6 | eb | 5b | 9d | 58 | 43 | 6d | 03 | 80 | 18 | ] | . XCm | ||
| 0030 | 18 | e9 | 83 | a2 | 00 | 00 | 01 | 01 | 08 | 0a | 1e | d8 | c6 | b4 | 1e | d8 | ||||
| 0040 | c6 | b4 | 00 | 41 | 00 | 00 | 00 | 07 | ff | 03 | 04 | 99 | 9a | c0 | 19 |
4.2. Échange de données


- Q38. À partir des éléments présentés, proposer une déclaration de la classe de ModbusData.
- Q39. Quel est le rôle de ce thread ?
- Q40. Dans la relation client / serveur, donner le rôle joué par l'application RollABoat.
- Q41.Préciser la relation dans le diagramme de classe entre NetBoatSlave et ModBusMaster. Comment ce type de relation est implémenté en C++ ou en Python.
- Q42. Quel mécanisme doit être mis en œuvre pour protéger ModbusData contre les écritures concurrentes ?
Partie 5 : Mise en exploitation du simulateur
5.1. Architecture réseau


Le routeur0 assure le pare-feu, le routage internet et le routage inter vlan (DMZ inclus). La DMZ est dans un VLAN dédié et routé par Routeur0.
- Q43. Préciser comment doit être configuré la liaison entre Routeur0 et Communateur0 pour qu'une architecture avec un serveur DMZ câblé sur le commutateur soit possible.
- Q44. Dans le document réponse DR44, lister les adresses IP utilisées Figure 19 par les différents équipements en commençant par le début de la plage.
- Q45. L'architecture réseau en production, Figure 20, possède deux simulateurs. Sur le document réponse DR45, proposer un plan d'adressage du simulateur 1 et 2 en utilisant les deux premiers sous réseau de la plage d'adresse 172.16.38.0/24. Les sous réseaux utilisent le masque /28.
- Q46. Dans le document réponse DR46, Proposer un plan d'adressage pour les matériels restants et déterminer la table de routage de routeur0.
Hypothèse : l'ensemble de la plage 172.16.38.0/24 est disponible.
| voilesurterre.fr | type d'enregistrement : | valeur : | TTL |
| @ | A | 11.22.33.44 | 14400 |
- Q47. Quel matériel répond à un ping sur www.voilesurterre.fr fait sur internet et avec quelle adresse IP ?
- Q48. Que faut-il faire pour que cela soit possible ? Préciser les ports et les matériels impactés par cette configuration.
5.2. Base de données
Le premier type de propositions porte sur les entités :
- -il existe des clients qui sont caractérisés par les noms, prénoms, n° de client, téléphone, adresse de facturation, @email, mot de passe crypté ;
- -il existe des simulateurs caractérisés par l'IP du routeur et le nom du technicien de maintenance ;
- -il existe des bateaux à simuler qui sont caractérisés par leur type et leur nom ;
- -il existe des sites de navigation caractérisés par des coordonnées GPS, un niveau de difficulté... ;
- -il existe des simulations qui sont caractérisées par la date de simulation.
- -une simulation porte sur un type de bateau ;
- -une simulation utilise un simulateur ;
- -un client peut réaliser plusieurs simulations ;
- -une simulation porte sur un site de navigation.

DOCUMENTS TECHNIQUES
DT2 - Documentation Vector3 Unity 3D ..... 3
DT3 - Modbus over TCP/IP ..... 5
DT4 - Protocoles usuels ..... 7
DT1 - Statistiques station météo
Ploumanac'h - Perros

| janv. | fev. | mars | avr. | mai | juin | |
| Vent
|
17.2 | 13.8 | 13.3 | 6.9 | 3.9 | |
| Vent
|
1.6 | 0.5 | 0.2 | 0.3 | 0.1 |
| juil. | août | sept. | oct. | nov. | dec. | Toute la période |
| 5.1 | 3.9 | 6 | 13.5 | 17.2 | 100.8 | |
| 0.1 | 0.1 | 0.2 | 0.9 | 4 |





DT2 - Documentation Vector3 Unity 3D
Constructeurs
- -Vector3(float x, float y, float z) : Crée un nouveau vecteur avec les composantes spécifiées.
- -Vector3(float value) : Crée un nouveau vecteur avec toutes les composantes égales à la valeur spécifiée.
- -Vector3(Vector2 vector, float z) : Crée un nouveau vecteur en utilisant les composantes x et y du vecteur spécifié et la valeur spécifiée pour la composante z.
- -magnitude (type : float) : La magnitude (longueur) du vecteur.
- -normalized (type : Vector3) : Le vecteur normalisé (de magnitude 1).
- -sqrMagnitude (type : float) : La magnitude au carré du vecteur.
- -Cross(Vector3 vector) (type : Vector3) : Calcule le produit vectoriel entre le vecteur et le vecteur spécifié.
- -Distance(Vector3 vector) (type : float) : Calcule la distance entre le vecteur et le vecteur spécifié.
- -Dot(Vector3 vector) (type : float) : Calcule le produit scalaire entre le vecteur et le vecteur spécifié.
- -Lerp(Vector3 to, float t) (type : Vector3) : Interpole linéairement entre le vecteur et le vecteur spécifié en utilisant le facteur spécifié t
(0 = vecteur,1 = vecteur spécifié). - -Max(Vector3 vector) (type : Vector3) : Retourne un vecteur contenant la plus grande valeur de chaque composante entre le vecteur et le vecteur spécifié.
- -Min(Vector3 vector) (type : Vector3) : Retourne un vecteur contenant la plus petite valeur de chaque composante entre le vecteur et le vecteur spécifié.
- -MoveTowards(Vector3 to, float maxDistanceDelta) (type : Vector3) : Déplace le vecteur vers le vecteur spécifié avec une distance maximale spécifiée.
- -Normalize() (type : void) : Normalise le vecteur (magnitude = 1).
- -Reflect(Vector3 normal) (type : Vector3) : Réfléchit le vecteur autour du vecteur spécifié.
- -Scale(Vector3 scale) (type : void) : Multiplie chaque composante du vecteur par la composante correspondante du vecteur spécifié.
- -ToString() (type : string) : Convertit le vecteur en une chaîne de caractères.
- -Set(float x, float y, float z) (type : void) : Définit les valeurs des composantes du vecteur.
- -Slerp(Vector3 to, float t) (type : Vector3) : Interpole sphériquement entre le vecteur et le vecteur spécifié en utilisant le facteur spécifié t
(0 = vecteur,1 = vecteur spécifié). - -SmoothDamp(Vector3 target, ref Vector3 currentVelocity, float smoothTime, float maxSpeed) (type : Vector3) : Calcule une position douce et amortie entre le vecteur et le vecteur spécifié.
Opérateurs de surcharge
- -+ (addition) : Ajoute deux vecteurs et retourne un nouveau vecteur résultant de l'addition.
- -- (soustraction) : Soustrait un vecteur d'un autre vecteur et retourne un nouveau vecteur résultant de la soustraction.
- -* (multiplication) : Multiplie un vecteur par un scalaire (float) et retourne un nouveau vecteur résultant de la multiplication.
- -/ (division) : Divise un vecteur par un scalaire (float) et retourne un nouveau vecteur résultant de la division.
- -== (égalité) : Compare si deux vecteurs sont égaux en termes de valeurs de leurs composantes et retourne un booléen indiquant si les vecteurs sont égaux ou non.
- -!= (différence) : Compare si deux vecteurs sont différents en termes de valeurs de leurs composantes et retourne un booléen indiquant si les vecteurs sont différents ou non.
- -- (négation) : Négation un vecteur et retourne un nouveau vecteur dont les composantes sont les opposées du vecteur d'origine.
- -[] (indexeur) : Permet d'accéder aux composantes d'un vecteur en utilisant des indices (0 pour x, 1 pour y, 2 pour z). et constructeur
// Déclaration des points A et B
Vector3 pointA = new Vector3(1.0f, 1.0f, 3.0f);
Vector3 pointB = new Vector3(4.0f, 5.0f, 4.0f);
// Création du vecteur AB en soustrayant le point A du point B
Vector3 vecteurAB = pointB - pointA;
Debug.Log("Vecteur AB : " + vecteurAB);
// Vecteur AB : (3.0, 4.0, 1.0)
// Multiplication du vecteur AB par 1/3
vecteurAB_R = AB * (1.0f / 3.0f);
// Addition du résultat avec le point A
Vector3 resultat = vecteurAB_R + pointA;

DT3 - Modbus over TCP/IP
Information is stored in the Slave device in four different tables. Two tables store on/off discrete values (coils) and two store numerical values (registers). The coils and registers each have a read-only table and read-write table. Each table has 9999 values. Each coil or contact is 1 bit and assigned a data address between 0000 and 270E. Coil/Register Numbers can be thought of as location names since they do not appear in the actual messages. The Data Addresses are used in the messages. For example, the first Holding Register, number 40001, has the Data Address 0000. The difference between these two values is the offset. Each table has a different offset: 1, 10001, 30001 and 40001.
| Coil/Register Numbers | Data Addresses | Type | Table Name |
| 1-9999 | 0000 to 270E | Read-Write | Discrete Output Coils |
| 10001-19999 | 0000 to 270E | Read-Only | Discrete Input Contacts |
| 30001-39999 | 0000 to 270E | Read-Only | Analog Input Registers |
| 40001-49999 | 0000 to 270E | Read-Write | Analog Output Holding Registers |
This number tells the slave which table to access and whether to read from or write to the table.
| Function Code | Action | Table Name |
| 1 (01 hex) | Read | Discrete Output Coils |
| 5 (05 hex) | Write single | Discrete Output Coil |
| 15 (0F hex) | Write multiple | Discrete Output Coils |
| 2 (02 hex) | Read | Discrete Input Contacts |
| 4 (04 hex) | Read | Analog Input Registers |
| 3 (03 hex) | Read | Analog Output Holding Registers |
| 6 (0 6 hex) | Write single | Analog Output Holding Register |
| 16 (10 hex) | Write multiple | Analog Output Holding Registers |
MBAP Header
Over IP, a 7-byte header called the MBAP header (Modbus Application Header) is added to the start of the message. This header has the following data:
- -Transaction Identifier: 2 bytes set by the Client to uniquely identify each request. These bytes are echoed by the Server since its responses may not be received in the same order as the requests.
- -Protocol Identifier: 2 bytes set by the Client, always = 0000
- -Length: 2 bytes identifying the number of bytes in the message to follow.
- -Unit Identifier: 1 byte set by the Client and echoed by the Server for identification of a remote slave connected on a serial line or on other buses.
PDU Transaction Formats (registers function code only)
| request | ||||
| 0 | 1 | 2 | 3 | 4 |
| 03 | address | number | ||
| response | ||||
| 0 | 1 | 2 | 3 | ... |
| 03 | N | data (N bytes) | ||
| request | ||||
| 0 | 1 | 2 | 3 | 4 |
| 04 | address | number | ||
| response | ||||
| 0 | 1 | 2 | 3 | ... |
| 04 | N | data (N bytes) | ||
| request | ||||
| 0 | 1 | 2 | 3 | 4 |
| 06 | address | value | ||
response = echo of the request
| request | |||||||
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | ... |
| 10 | address | number | N | data | |||
| response | ||||
| 0 | 1 | 2 | 3 | 4 |
| 10 | address | number | ||
Following a request, there are 4 possible outcomes from the slave.
- -The request is successfully processed by the slave and a valid response is sent.
- -The request is not received by the slave therefore no response is sent.
- -The request is received by the slave with a parity, CRC or LRC error. The slave ignores the request and sends no response.
- -The request is received without an error, but cannot be processed by the slave for another reason. The slave replies with an exception response.
DT4 - Protocoles usuels
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
| Préambule | |||
| préambule | |||
| adresse destination (0-3) | |||
| adresse destination (4-5) | |||
| adresse source (2-5) | |||
| données (0 à 1500 octets) | |||
| bourrage (0 à 46 octets) | |||
| contrôle | |||
adresse destination : codée sur 48 bits (FF:FF:FF:FF:FF:FF pour diffusion)
adresse source : codée sur 48 bits
type des données : identification du protocole couche supérieure
( 0x0800 pour IP, 0x0806 pour ARP ...)
données : données de la couche supérieure
bourrage : la longueur minimale d'une trame ethernet est de 64 octets
(sans compter le préambule). Si les données ont une longueur inférieure à 46 octets, le champ bourrage est utlisé.
| Octet 1 | Octet 2 | Octet 3 | Octet 4 | |||
| Mot 1 | Version | Long | Type de service | Longueur totale | ||
| Mot 2 | Identification | Flags | Position fragment | |||
| Mot 3 | Temps de vie | Protocole | Checksum en-tête | |||
| Mot 4 | Adresse station source | |||||
| Mot 5 | Adresse station destinataire | |||||
| Mot 6 | Options | Bourrage | ||||
Type de service : désigne la qualité de service désirée pour le datagramme.
| Précédence | D | T | R | 0 | 0 |
T signifie Troughput (débit)
R signifie Reliability (fiabilité)
Longueur totale : longueur totale du datagramme mesurée en octets, y compris l'en-tête IP et les données.
Identification : identification pour reconstituer les différents fragments d'un datagramme.
Flags : champ de trois bits gérant la fragmentation
000 - autorise la fragmentation, dernier fragment,
001 - autorise la fragmentation, ce n'est pas le dernier fragment,
010 - fragmentation non autorisée.
Position : indique la position d'un fragment, comptée en octet par rapport au début des données du paquet complet. Si le datagramme est complet, ou s'il s'agit du premier fragment, ce champ est à 0.
Protocole : définit le numéro de SAP qui recevra le paquet.
liste des protocoles les plus connu :
- -01-00001 - ICMP
- -02-00010 - IGMP
- -06-00110 - TCP
- -17-10001 - UDP
Adresse source et destination : adresses codées sur 32 bits.
Options : champ de longueur variable en fonction du type et du nombre d'options.
Bourrage : valeur de remplissage pour obtenir une en-tête avec un nombre entier de mots de 32 bits.
TCP
| Octet 1 | Octet 2 | Octet 3 | Octet 4 | |
| Mot 1 | Port source | Port destination | ||
| Mot 2 | Numéro de séquence | |||
| Mot 3 | Numéro d'acquittement | |||
| Mot 4 | Contrôle | Fenêtre | ||
| Mot 5 | Checksum | Urgent pointer | ||
| Mot 6 | Options | |||
| Mot 7 | Donnnées | |||
- -Port source et destination : nombres de 16 bits qui identifient la connexion (correspondent à l'application de la couche supérieure,
- -Numéro de séquence : permet de rétablir l'ordre des paquets reçus et d'éliminer les paquets dupliqués,
- -Numéro d'acquittement : si le flag ACK est présent, désigne le prochain numéro de séquence qui sera transmis par l'autre bout de la connexion,
- -Contrôle :
offset données ( 4 bits) : indique le nombre de mots de 32 bits de l'en-tête TCP, réservé ( 6 bits) : zone toujours à zéro,
FLAGS (6 bits) : zone composée des bits U, A, P, R, S, F
U : segment à traiter en Urgence,
A : le segment transporte un numéro d'acquittement significatif,
P : si le paquet reçu comporte ce flag, TCP le transmet immédiatement à la couche supérieure sans attendre d'autres segments (utile par exemple pour un fonctionnement correct d'un écho sur une console),
R : provoque un Reset de la connexion,
S : demande de connexion, permet la synchronisation des numéros de séquence,
F : Fin, plus de données à transmettre. - -Fenêtre : indique le nombre d'octets qui seront acceptés par la station émettrice à partir de celui indiqué par le numéro d'acquittement présent dans le segment.
- -Checksum : complément à 1 de la somme des mots de 16 bits de l'en-tête TCP et des données,
- -Urgent pointer : si le flag U est à 1 , indique en nombre d'octets le décalage par rapport au numéro de séquence de ce segment des données à traiter en urgence,
- -Options :
| type | longueur | signification |
| 0 | - | fin de la liste des options |
| 1 | - | pas d'opération |
| 2 | 4 | longueur maximum d'un segment |
| 4 | - | SACK permis |
- -Données : données provenant de la couche supérieure à TCP.

NE RIEN ECRIRE DANS CE CADRE
Proposer la suite du plan d'adressage
| Equipements | Adresse IP (à compléter) | |
| Sous réseau №3 | Serveur site production | 172 . . / |
| Routeur0-production | 172 . . / | |
| Routeur simu 1 Côté Routeur0 | 172 . . / | |
| Routeur simu 2 Côté Routeur0 | 172 . . / | |
| Sous réseau №4 | Serveur site DMZ | 172 . . / |
| RouteurO-DMZ : | 172 . . / |
(Rq : le nombre de lignes ne présume pas un nombre de routes statiques)
| Réseau | Masque | IP passerelle | Interface de sortie |
DOCUMENTS RÉPONSES

Trame №1 :
| Type de trame | |
| IP émetteur | |
| IP récepteur | |
| Port destination | |
| Registre(s) concerné(s) | |
| Données brutes | |
| Données décodées | |
| Nom du registre / Nom des registres |
| Type de trame | |
| IP émetteur | |
| IP récepteur | |
| Port destination | |
| Registre(s) concernés | |
| Données brutes | |
| Données décodées | |
| Nom du registre / Nom des registres |
| Equipements (à compléter) | Adresse IP (à compléter) |
| AUTOMATE | 172 . . / |
| Equipements simulateur 1 | Adresse IP (à compléter) | |
| Sous réseau №1 | AUTOMATE(1) | 172 . . / |
| IHM (1) | 172 . . / | |
| RollABoat (1) | 172 . . | |
| Routeur simu1 côté armoire de commande | 172 . . / |
| Equipements simulateur 2 | Adresse IP (à compléter) | |
| Sous réseau №2 | AUTOMATE (2) | 172 . . / |
| IHM (2) | 172 . . / | |
| RollABoat (2) | 172 . . / | |
| Routeur simu2 côté armoire de commande | 172 . . / |
Questions fréquentes
4 questionsSur quels chapitres porte l'épreuve écrite disciplinaire du CAPET ingénierie informatique 2024 ?Afficher ou masquer la section
Questions fréquentes
4 questionsSur quels chapitres porte l'épreuve écrite disciplinaire du CAPET ingénierie informatique 2024 ?
Le sujet, basé sur un simulateur de voilier, porte sur la modélisation UML, la programmation orientée objet en C++, le protocole Modbus/TCP-IP et les bases de données relationnelles avec des requêtes SQL.
Quelles erreurs le jury a-t-il le plus relevées sur ce sujet du CAPET ingénierie informatique 2024 ?
Le jury relève des lacunes sur les relations UML (extend, héritage), des erreurs de calcul en interpolation bilinéaire, une méconnaissance des threads et du MUTEX, ainsi que des faiblesses sur le routage réseau et les contraintes référentielles en base de données.
Quelle partie du sujet CAPET ingénierie informatique 2024 est la moins bien réussie ?
La partie 5, sur la mise en exploitation en réseau et la base de données, est la moins bien maîtrisée : seuls 4 % des candidats proposent une table de routage correcte et environ 30 % un schéma de base de données satisfaisant.
Faut-il maîtriser les réseaux pour ce sujet du CAPET ingénierie informatique 2024 ?
Oui, la partie 4 porte sur la communication Modbus/IP et l'analyse de trames TCP/IP, et la partie 5 sur l'architecture réseau et l'adressage IP, deux domaines où le jury signale des lacunes importantes.
Pas de description pour le moment