Agrégation informatique externe 2024, épreuve 2, option ingénierie informatiqueSujet et rapport du jury

AGREGATION
CONCOURS EXTERNE

INFORMATION AUX CANDIDATS

Ces codes doivent être reportés sur chacune des copies que vous remettrez.

Optimisation de la production d'un spécialiste des pâtisseries et produits traiteurs surgelés.

Figure 1 - Répartition des usines en France

Figure 2 - Architecture de la récolte des données et leur traitement

Figure 3 - Capture d'écran OFActifs (Ordres de Fabrications actifs)

• -TRS : Taux de Rendement Synthétique
• -TRG : Taux de Rendement Global
• -TRE : Taux de Rendement Économique

Figure 4 - Indicateurs de performance

• -Qualification du modèle choisi pour le calcul du TRS
  Les lignes de production de la pâtisserie étant modulaires (adaptables à la production), cette première partie consistera à tenter d'identifier par analyse statistique les différentes équations représentatives du TRS et de la propagation du défaut afin d'en extraire un modèle. Une analyse de la base de données de l'application suivra afin d'être en mesure de proposer des améliorations.
• -Estimation de l'efficacité de la récolte des données en matière de transmission
  Cette seconde partie portera sur l'analyse des modules logiciels existant, leur modélisation UML et l'impact des réseaux sur l'efficacité de la récolte des données.
• -Amélioration du modèle choisi pour l'identification des défauts en sortie de four
  Dans cette troisième partie, il va s'agir d'analyser et de modéliser le fonctionnement de l'application existante en lien avec la reconnaissance des pâtisseries en sortie de four, de modéliser le refroidissement du gâteau et de proposer une amélioration.

• -Impact d'un transfert du Deep Learning vers le Cloud
  Dans cette dernière partie, il va s'agir de modéliser différentes situations de transfert entre les usines et le Cloud afin de vérifier la possibilité de traiter les images dans le Cloud.

Partie 1. Qualification du modèle choisi pour le calcul du TRS

Figure 5 - Exemple de ligne de production de l'usine de Dabas.

Point de vue productivité

Figure 6 - Ligne de production comportant n éléments en parallèle

Figure 7 - Capture d'un onglet de l'interface web temps réel

• -I'état de fonctionnement nominal (m) pour lequel le TRS est supérieur ou égal à 85 %
• -I'état de fonctionnement dégradé (md) pour lequel le TRS est inférieur à 85 % mais supérieur à 25 %
• -l'état hors service (hs) pour lequel le TRS est inférieur ou égal à 25 %.

• -TA qui représente les temps d'arrêt auxquels s'ajoutent les écarts de cadence et les retards dus à la non qualité,
• -TR qui représente le temps requis.

Figure 8 - Récolte des données sur une ligne de production

Partie 2. Estimation de l'efficacité de la récolte des données

Figure 9 - Partie locale de l'installation

• -lire l'ensemble des registres et bits de ce périphérique avec les méthodes read_coils(adresse, count, unit) et read_holding_registers(addr_from, number, unit) de mb_client,
• -transformer les données récoltées en message au format JSON à l'aide de la méthode msg_mqtt(name, value),
• -publier vers le serveur MQTT avec la méthode publish(topic, payload) de mqtt_client.

Analyse de l'impact des réseaux

Figure 10 - Protocoles utilisés

• Q21.Après analyse des documents techniques DT4 et DT3, calculer la taille de la requête puis celle de la réponse Modbus TCP dans la transaction qui lit les « holding registers ». En déduire la taille de la trame Ethernet qui encapsule la requête puis celle de la réponse. Justifier les 4 résultats.
• Q22.Après analyse des documents techniques DT4 et DT3, calculer la taille de la requête puis celle de la réponse Modbus TCP dans la transaction qui lit le « coils ». En déduire la taille de la trame Ethernet qui encapsule la requête puis celle de la réponse. Justifier les 4 résultats.

Figure 11 - Détail des échanges TCP par transaction Modbus

• -T_req : temps de transmission d'une trame requête Modbus,
• -T_pro : temps de propagation entre le client et le serveur,
• -T_tmt : temps de traitement d'une requête Modbus par le serveur,
• -T_res : temps de transmission d'une trame réponse,
• -T_syn : temps de transmission d'une trame de synchronisation TCP SYN,
• -T_syn_ack : temps de transmission d'une trame TCP SYN-ACK,
• -T_ack : temps de transmission d'une trame TCP ACK,
• -T_fin : temps de transmission d'une trame TCP FIN.

• -l'automate de la figure 10 et le serveur Edge sont interconnectés par une liaison directe Ethernet full-duplex à 10Mbit ⋅ s^(− 1),
• -la taille des trames (y compris l'entête et le checksum Ethernet) est la suivante : TCP_SYN = 78 octets, TCP_SYN_ACK = TCP_ACK = TCP_FIN = 70 octets,
• -le temps moyen de traitement (t_tmt) est de 65μ s,
• -la longueur moyenne de la liaison Ethernet est de 100 m et la vitesse de propagation du signal électrique dans le câble est de 200000 km ⋅ s^(− 1).

Figure 12 - Connexion TCP pour une transaction "holding register" et une transaction "read coils"

Réseau Ethernet commuté travaillant au débit de 10 Mbit ⋅ s^(− 1)

Figure 13 - Réseau Modbus TCP sur Ethernet commuté

Figure 14 - Modèle de file d'attente dans le commutateur Ethernet

• Q26.Exprimer et calculer la durée minimale de la connexion TCP qui réalise 1 transaction « holding_register » et 1 transaction « read_coils » entre le serveur Edge et un automate. Détailler le raisonnement.

Figure 15 - Réseau de K caméras et M automates

• Q28.Exprimer, en fonction de M et K de la figure 15, la durée maximale d'une connexion TCP Modbus qui réalise les deux transactions précédentes. En déduire le nombre d'automates et de caméras supportés par le système.

Réseau Wifi

Figure 16 - réseau local Wi-Fi pour interconnecter M automates et K caméras

Figure 17 - Envoi d'une trame de données serveur Edge vers automate

Figure 18 - Format de la trame Wi-Fi

Figure 19 - Illustration d'un envoi dans le cas où le canal est occupé

Partie 3. Amélioration du modèle choisi pour l'identification des défauts en sortie de four

Figure 20 - Exemple de plateau utilisé

Figure 21 - Principe de la valorisation de la donnée

class FLIR(object):
    def __init__(self, host):
        self.tn = None
        self.host = host
        self.port = 23
        self.timeout = 2

cam = flir('192.168.1.10')
while True:
    mqtt_client.initPayload(cam)
    cam.connect()
    cam.slowFocus()
    filename = cam.shootJPG('')
    src = cv.imread(filename)
    src_gray = cv.cvtColor(src, cv.COLOR_BGR2GRAY)
    img_blur = cv.GaussianBlur(src_gray, (3,3),3,10,cv.BORDER_CONSTANT )
    lesCircles = cv.HoughCircles(img_blur, cv.HOUGH_GRADIENT,1,90,param1=56,
    | | | | | \
    ch=1
    if lesCircles is not None:
        lesCircles = np.round(lesCircles[0, :]).astype("int")
        for (x, y, r) in lesCircles:
            payload = mqtt_client.addPayload('x:{0},y:{1},r:{2}'.format(x,y,r))
            ch=ch+1
        mqtt_client.publish(
            topic='dt/device_data/{0}'.format(device['name']),
            payload=json.dumps(payload))
    time.sleep(2)

• -plus de gâteaux sont détectés avec un défaut par l'application que par l'opérateur humain,
• -des gâteaux sont positionnés à des endroits incohérents par rapport à l'observation.

Figure 23 - Exemple de résultat après traitement d'une image

Figure 24 - Diagramme d'activité SysML partiel et simplifié de la solution envisagée

• Q38.Interpréter le diagramme de la figure 24 et décrire comment la mise en œuvre de ce modèle peut résoudre les problèmes constatés.

• Q39.Vérifier que la caméra permet bien la mise en œuvre de ce modèle. Justifier.

Modélisation de la répartition de la chaleur

Le modèle choisi pour le gâteau est un cylindre de rayon 90 mm et de hauteur 25,2 mm. Sa masse sera de 95 g.

Les hypothèses destinées à simplifier la suite du sujet seront :

• -le système {gâteau} est incompressible,
• -il n'y a pas de transfert par travail lors du refroidissement,
• -il n'y a pas d'énergie mécanique lors du refroidissement.

• -seule la surface supérieure du gâteau est soumise à l'air ambiant,
• -la moitié du gâteau (toujours posé sur la tapis) est soumis à l'air ambiant,
• -le gâteau entier (toujours posé sur la tapis) est soumis à l'air ambiant.

• -surface élémentaire de tapis considérée : L = I = 110 mm
• -épaisseur du tapis : e = 0,6 mm
• -masse volumique du tapis : m_(v_t) = 1200 kg ⋅ m^(− 3)
• -capacité thermique massique du tapis : C_(m_t) = 1674 J ⋅ kg^(− 1) ⋅ m^(− 1)

Partie 4 - Impact d'un transfert du Deep Learning vers le Cloud

Figure 25 - Topologie du réseau de transport TRS

• -1 ligne de production comporte 5 automates,
• -1 ligne de production contient 1 four,
• -1 usine compte 5 lignes de production,
• -1 image d'au maximum 153600 octets est transmise toutes les 3 s,
• -1 message MQTT « Publish » fait 257 octets au maximum, y compris l'entête et le checksum Ethernet,
• -1 message MQTT est construit pour chacune des 4 informations,
• -1 message MQTT est construit pour chaque « coil »,
• -le réseau local est basé sur Ethernet commuté décrit précédemment.

• Q49.Calculer le débit à réserver dans le cas où les images sont traitées par les services AWS. Justifier le résultat et conclure.

• Q50.À l'aide de l'algorithme de Dijkstra, trouver, document réponse DR4, et proposer le chemin le plus court du centre de données AWS vers chacun des sites.

• Q51.Si la probabilité de perte de paquets dans chaque routeur est égale à p, exprimer la probabilité qu'un paquet partant du site de Dabas arrive au serveur AWS avec succès.

Figure 26 - Files d'attente dans le routeur 4

• Q52.Exprimer en fonction de D1 [Mbit ⋅ s^(− 1)], D3 [Mbit ⋅ s^(− 1)] et p puis calculer la valeur minimale du taux de service s2 pour assurer que le taux de perte d'un paquet MQTT est égal ou inférieur à p.

Document technique DT1 : organisation ou lexique

Lambda ( λ )

est un service informatique qui permet d'exécuter un code sans demander la mise en service ou la gestion des serveurs.

Document technique DT2 : extrait de la requête Athena de construction des données d'affichage d'un ordre de fabrication

select /* infos Ordres de Fabrication */
    "OF".id,
    "OF".fabricationOrder,
    "OF".factory,
    "OF".responsible,
    "OF".line,
    "OF".fabricationNumber,
    "OF".fabricationName,
    "OF".clientId,
    "OF".clientLabel,
    "OF".startDateYear,
    "OF".startDateHour,
    "OF".startDate_timestamp,
    "OF".endDateYear,
    "OF".endDateHour,
    "OF".endDate_timestamp,
    "OF".state,
    "OF".processed,
    "OF".img,
    "OF".numberOfItems,
    "OF".productFamily,
    "OF".format,
    "OF".breadFamily,
    "OF".deliveryType,
    "OF".packagingType,
    "OF".budgetPeopleNb,
    "OF".budgetRate,
    "OF".nominalRate,
    "OF".outUV,
    "OF".finalUV,
    "OF".weightUV,
    "OF".unitPRV,
    OF_events_first.start_timestamp as Actual_startDate_timestamp,
    OF_events_last.start_timestamp as Actual_EndDate_timestamp,
    cast( (OF_events_last.start_unixtime - OF_events_first.start_unixtime) as double) /
    1000 / 3600 as temps_ouverture,
    temps_ouverture - cast( (OF_events_eat.start_unixtime - OF_events_eat.start_unixtime) as double) /
    1000 / 3600 as temps_requis,
    (OF_events_last.conform / "OF".nominalRate ) / temps_requis as TRS,
    thisOF_history.delta as nb_plateau_deb_periode
from
    "OF"
        left join
        (
            select *
            from OF_events
            where num_event_tab=1
        ) as OF_events_first
            on "OF".fabricationOrder=OF_events_first.fabricationOrder
        left join
        (
            select *
            from OF_events
            where reason_name='Arrêt' and completed=true
        ) as OF_events_last
            on "OF".fabricationOrder=OF_events_last.fabricationOrder
        left join
        (
            select *
            from OF_events
            where reason_name='Repas'
        ) as OF_events_eat
            on "OF".fabricationOrder=OF_events_last.fabricationOrder

List of reserved keywords in SQL SELECT statements

ALTER, AND, AS, BETWEEN, BY, CASE, CAST,
CONSTRAINT, CREATE, CROSS, CUBE, CURRENT_DATE, CURRENT_PATH,
CURRENT_TIME, CURRENT_TIMESTAMP, CURRENT_USER, DEALLOCATE,
DELETE, DESCRIBE, DISTINCT, DROP, ELSE, END, ESCAPE, EXCEPT,
EXECUTE, EXISTS, EXTRACT, FALSE, FIRST, FOR, FROM, FULL, GROUP,
GROUPING, HAVING, IN, INNER, INSERT, INTERSECT, INTO,
IS, JOIN, LAST, LEFT, LIKE, LOCALTIME, LOCALTIMESTAMP, NATURAL,
NORMALIZE, NOT, NULL, OF, ON, OR, ORDER, OUTER, PREPARE,
RECURSIVE, RIGHT, ROLLUP, SELECT, SKIP, TABLE, THEN, TRUE,
UNESCAPE, UNION, UNNEST, USING, VALUES, WHEN, WHERE, WITH

• -Min(), max() - The min() and max() aggregation functions now allow unknown input types at query analysis time so that you can use the functions with NULL literals.

Document technique DT3 : extraits du code de la passerelle Modbus/MQTT et documentation python time sleep (2 pages)

import greengrasssdk # noqa
from pymodbus.client.sync import ModbusTcpClient as ModbusClient # noqa
from pymodbus.payload import BinaryPayloadDecoder # noqa
from pymodbus.constants import Endian # noqa
with open('bonnepat.json') as json_file:
    config = json.load(json_file)
HOSTS = os.environ.get('HOSTS', '{0}:{1}'.format(config['mqtt_host'],config['modbus_port']))
POLL_INTERVAL = os.environ.get('POLL_INTERVAL', config['polling_freq'])
UNIT = os.environ.get('UNIT', 1)
mqtt_client = greengrasssdk.client('iot-data')
mb_clients = get_modbus_clients(HOSTS)
while True:
    for mbc in mb_clients:
        for device in config['servers']:
            poll_device(mbc, device, mqtt_client)
    time.sleep(POLL_INTERVAL)

v {
    "mqtt_host" : "127.0.0.1",
    "polling_freq" : 5,
    "modbus_port" : 5020,
    "servers" :
    [
        {
            "name":"Doseuse_A",
            "hr_addr_from" : 150,
            "hr_addr_to" : 157,
            "holding_registers":
            [
                { "name":"compteur_plateaux", "address":150 },
                { "name":"niveau_réservoir1", "address":152 },
                { "name":"niveau_réservoir2", "address":154 },
                { "name":"courant", "address":156 }
            ],
            "coils":
            [
                { "name":"marche_production", "address":150 },
                { "name":"marche_reglage", "address":151 },
                { "name":"marche_vidange", "address":152 },
                { "name":"marche_lavage", "address":153},
                { "name":"arret_ligne", "address":154 },
                { "name":"defautAUZ1", "address":155 },
                { "name":"defautAUZ2", "address":156 },
                { "name":"defaut_bras_1", "address":157 },
                { "name":"defaut_bras_2_3", "address":158 },
                { "name":"defaut_boucle_entremet", "address":159 },
                { "name":"defaut_movifitZ1", "address":160 },
                { "name":"defaut_movifitZ2", "address":161 }
            ]
        },

Document technique DT4 : extrait de documentation Modbus TCP (2 pages)

Format d'une requête ou d'une réponse Modbus (Modbus ADU - Application Data Unit)

• -Transaction Identifier - It is used for transaction pairing, the MODBUS server copies in the response the transaction identifier of the request.
• -Protocol Identifier - It is used for intra-system multiplexing. The MODBUS protocolis identified by the value 0 .
• -Length - The length field is a byte count of the following fields, including the Unitldentifier and data fields.
• -Unit Identifier - This field is used for intra-system routing purpose. It is typicallyused to communicate to a MODBUS+ or a MODBUS serial line slave through agateway between an Ethernet TCP-IP network and a MODBUS serial line. This field

6.101 (0x01) Read Coils

• N = Quantity of Outputs / 8, if the remainder is different of 0 ⇒ N = N + 1
  6.303 (0x03) Read Holding Registers

• N = Quantity of Registers

Document technique DT5 : Documentation méthodes opencv

Document technique DT6 : extrait de la documentation ftplib et de la fonction native open de python avec annotations

• When host is given, the method call connect(host) is made.

Document technique DT7 : Extrait documentation caméra et Serveur Edge

• -plage de températures de l'objet -20 à +120 °C (-4 à 248 °F) ou 0 à +350 °C (32 à 662 °F) selon réglages
• -précision ±2 °C ou ±2 % de la valeur lue
• -résolution IR 320 × 240 pixels - 16 bits
• -sensibilité thermique/NETD < 0,05 °C à +30 °C/50 mK
• -gamme spectrale : 7.5μ m à 13μ m
• -fréquence image 8-9 Hz
• -connexion 100 Mb Ethernet compatible Ethernet/IP et modbus TCP
• -On schedule: file sending (FTP) or e-mail (SMTP) of analysis results or images.
• -On alarms: file sending (FTP) or e-mail (SMTP) of analysis results or images.
• -distance minimale de focus : 0.4 m
• -FOV 25^∘ × 18.8^∘ mise au point motorisée et mise au point automatique.
• -IRMonitor Software
• -constante de temps du détecteur : 12 ms
• -External power operation : 12/24 V, 24 W max
• -difference temperature alarms with a dynamically updated reference temperature.

Document technique DT8 : Temps de Back-off Wi-Fi

Document technique DT9 : Algorithme de Dijkstra

Le nœud ayant le coût le plus court (nœud 7) est choisi comme le nœud déjà examine et ajouté dans la liste L. Dans chacun des étapes suivantes, l'algorithme essaie d'aller un saut plus loin à partir du nœud qui vient d'être ajouté à la liste L. Les coûts des chemins vers les nœuds hors de la liste L sont mis à jour si en passant par ce nœud l'algorithme trouve un meilleur chemin. Après la mise à jour, le nœud ayant le coût le plus faible à partir du nœud source est ajouté à la liste L. Ainsi de suite, à chaque étape, un nouveau nœud est considéré comme le nœud déjà examiné et ajouté à la liste L, jusqu'à ce que tous les nœuds du réseau se trouvent dans la liste L.

Document réponse DR1

Document réponse DR2

Document réponse DR4