Comment le modèle OSI garantit la fiabilité des communications et les différences entre TCP et IP

Le modèle OSI est une référence fondamentale pour comprendre la manière dont les données circulent dans un réseau. Il décompose les processus complexes de communication en sept couches distinctes, permettant ainsi de structurer la gestion de la communication réseau. À travers ces couches, différentes fonctions sont effectuées, allant de l’envoi brut de bits à la gestion des connexions applicatives.

L’une des premières préoccupations du modèle OSI est de garantir que les données envoyées d’un hôte à un autre arrivent de manière fiable et dans leur ordre d’origine. Dans cette optique, la couche de transport joue un rôle clé en assurant l'intégrité des flux de données. En effet, à chaque transmission de données, un contrôle de somme de contrôle (checksum) est effectué, afin de vérifier que les octets envoyés n'ont pas été altérés pendant leur transit. Si la somme de contrôle calculée par le récepteur diffère de celle envoyée par l'émetteur, une erreur est détectée et une retransmission est lancée.

L’une des tâches de la couche de transport consiste également à découper de longues séquences d’octets en paquets plus petits, qui peuvent être gérés efficacement par le protocole de transport utilisé. Ce processus de segmentation et de réassemblage permet une gestion optimale des paquets, en particulier lorsque ces derniers traversent des réseaux de grande envergure ou des infrastructures hétérogènes. À l'arrivée, les paquets sont réorganisés dans l'ordre exact et envoyés à la couche de session pour traitement supplémentaire.

Par ailleurs, la couche réseau est responsable de la gestion du routage des messages. Elle se charge de déterminer le chemin optimal pour envoyer un paquet, y compris la sélection des nœuds intermédiaires nécessaires si les hôtes source et destination sont sur des réseaux différents. Cependant, contrairement à la couche de transport, la couche réseau ne garantit pas la fiabilité de la transmission. Elle se contente de s’assurer que le paquet soit bien envoyé vers sa destination, sans se soucier de son intégrité une fois le paquet en transit.

Au niveau de la couche de liaison de données, l’accent est mis sur la gestion du transfert entre deux hôtes directement connectés, comme c’est le cas pour un lien Ethernet. Cette couche veille à l’accès au média physique, vérifie si ce dernier est déjà utilisé et gère l’erreur de transmission sur le support physique. La couche physique, quant à elle, concerne la conversion des bits logiques en signaux physiques, comme les tensions dans les câbles ou les ondes radio dans les réseaux sans fil. Ce niveau se concentre sur des caractéristiques spécifiques aux supports, telles que les débits de transmission ou les modes duplex.

Les systèmes d'exploitation modernes assurent les services des différentes couches du modèle OSI, notamment par des pilotes de périphériques pour la couche physique. Cependant, pour les systèmes embarqués, il est fréquent que ces systèmes ne supportent pas toutes les couches du modèle OSI. Dans ce cas, les concepteurs doivent ajouter du matériel et du logiciel pour implémenter certaines couches, notamment celles qui garantissent une communication avec Internet, comme les couches de transport et de réseau.

Le IP, en revanche, se concentre uniquement sur le routage des paquets vers leur destination. Il n’assure pas la fiabilité de la transmission. En effet, l'intégrité des données est une responsabilité de la couche de transport (principalement TCP). Cela signifie que, bien que le protocole IP soit essentiel pour la transmission de données entre réseaux, il ne garantit pas que ces données arrivent en bon état. C’est là que le rôle du TCP entre en jeu, en assurant que les paquets IP arrivent correctement et dans l'ordre prévu.

Pour la gestion de ces protocoles dans des systèmes embarqués, une équipe de conception devra comprendre au moins les principes de base de TCP et IP, particulièrement dans le cadre de la connectivité Internet. En effet, les systèmes embarqués ne possèdent pas toujours des ressources suffisantes pour gérer toutes les couches OSI de manière native, et il peut être nécessaire de programmer des éléments spécifiques pour garantir la bonne communication réseau.

Pour des applications telles que la surveillance des patients, un système embarqué peut être conçu pour gérer plusieurs processus concurrentiels, chacun nécessitant un numéro de port distinct pour les connexions TCP. Cela permet à différents processus d’échanger des données en parallèle sans interférer les uns avec les autres. Par exemple, un appareil utilisé pour surveiller les patients pourrait avoir un processus pour les rapports réguliers et un autre pour les alertes d’urgence, chacun utilisant son propre port TCP.

Il est important de souligner que, bien que la fiabilité du TCP soit cruciale pour de nombreuses applications, d’autres protocoles, comme le UDP (User Datagram Protocol), peuvent être plus appropriés dans des contextes nécessitant des communications en temps réel, telles que la vidéo ou l'audio en streaming. Le UDP, contrairement au TCP, ne garantit pas la livraison des paquets, mais il offre des avantages en termes de performance et de latence, ce qui peut être essentiel pour certaines applications.

Comment générer des cas de test à partir de modèles de systèmes discrets ?

L'objectif du test est de vérifier que la place P9 (nombre de pièces dans la zone de préparation) ne contient jamais plus de trois jetons. Il est supposé que les transitions se déclenchent dès qu'elles sont activées et que plusieurs transitions activées peuvent se déclencher simultanément, sauf si elles sont bloquées. Dans ce dernier cas, l’une des transitions est sélectionnée de manière aléatoire pour se déclencher. Dès qu’une transition se déclenche, les marquages dans le pré-ensemble de cette transition sont immédiatement modifiés. Cela empêche, par exemple, le robot 2 de penser que la zone de préparation est vide alors que le robot 1 est en train d'y placer une pièce. Un événement est créé pour le moment où cette transition est terminée, et les marquages dans le post-ensemble sont modifiés lorsque la transition est terminée.

Supposons que le modèle de réseau de Petri ait le marquage représenté dans la figure 5.5. À l'instant 0, deux transitions sont activées : T1 et T4. L'événement à l'instant 0 est traité, créant deux nouveaux événements – le robot 1 arrive dans la zone de stockage commune à l'instant 20, et le robot 2 y arrive à l'instant 3. L'événement à l'instant 3 est traité, modifiant les marquages : P5 reçoit un jeton. Aucun autre événement n'est créé puisque aucune autre transition n'est activée.

À l'instant 26, la transition T2 se termine et deux nouveaux marquages sont créés, P3 et P9 recevant chacun un jeton. La transition T3 s'active et retire un jeton de P3, tandis que T5 reste désactivée car P8 ne contient pas de jeton. Après cela, un nouvel événement est créé pour le temps à l'instant 31, où T3 se termine et modifie les marquages de P1 et P8. À cet instant, T1 et T5 se déclenchent simultanément, retirant un jeton de chaque place dans leurs pré-ensembles respectifs. Si l'on suppose que la durée de la transition T1 est de 25 secondes et celle de T5 de 7 secondes, de nouveaux événements sont générés, lesquels sont ajoutés à la file d'attente.

Le processus de génération de cas de test pour un modèle ou un produit par simulation d'événements discrets consiste à tester le produit avec autant de cas de test différents que possible. L'ensemble de cas de test doit couvrir tous les cas d'utilisation ainsi que tous les scénarios pertinents pour chaque cas d'utilisation. Certains tests peuvent également être dérivés directement des exigences, en prenant par exemple des hypothèses sur la vitesse d'un bateau, qui devrait être en mesure de passer du capteur amont au capteur aval dans un délai de 150 secondes dans des conditions normales (sans erreurs ni urgences).

Les tests peuvent être générés par un processus de brainstorming, à partir des cas d'utilisation et des scénarios définis lors de l'analyse comportementale. Une fois ces scénarios établis, des séquences d'événements avec des temps associés aux stimuli des acteurs peuvent être créées. Ce processus peut se baser sur des exigences précises comme la durée nécessaire pour effectuer certaines actions, par exemple le temps pour lever ou abaisser un pont. Ces tests devront aussi inclure des plages de temps, en générant des cas à partir des valeurs limites de ces plages.

Cependant, pour des modèles internes plus complexes comme les machines à états finis (FSM) ou les réseaux de Petri, la génération des cas de test demande des considérations supplémentaires par rapport à la phase initiale de brainstorming. Ces modèles intègrent des détails internes et des actions qui ne sont pas explicitement présents dans les modèles comportementaux. Par exemple, un FSM pourrait spécifier des détails d'opération internes comme des minuteries, qui auront un impact sur les contraintes temporelles au niveau comportemental.

Pour tester des systèmes distribués, des problèmes de concurrence doivent aussi être pris en compte. Les problèmes de concurrence peuvent surgir lorsque des messages sont envoyés d'un module à un autre, ou lorsqu’un événement interne se produit presque simultanément à l'arrivée d'un message. Les cas de test doivent donc être générés pour étudier les comportements de ces événements dans différentes configurations temporelles.

Lorsque des outils de simulation automatisée sont utilisés, des générateurs de nombres aléatoires peuvent être employés pour générer des cas de test. Par exemple, des nombres aléatoires peuvent être utilisés pour générer des temps dans une plage spécifiée, ce qui permet de tester la réactivité du système à des situations variées. Les générateurs peuvent aussi utiliser des distributions de probabilité pertinentes (comme la distribution de Poisson pour les temps d'arrivée des clients dans un distributeur automatique). Des centaines, voire des milliers de cas de test peuvent être générés et exécutés à l'aide de ces outils, ce qui permet de collecter des données statistiques sur les propriétés clés du système, notamment sur la manière dont il se comporte au fil du temps.