Spelling suggestions: "subject:"mixed criticité"" "subject:"mixed criticità""
1 |
Mixed criticality management into real-time and embedded network architectures : application to switched ethernet networks / Gestion de la criticité mixte dans les réseaux temps-réel embarqués et application à ethernet commutéCros, Olivier 08 December 2016 (has links)
La CM (Criticité Mixte) est une solution pour intégrer différents niveaux de criticité dans le même système au sein des mécanismes industriels intégrant des infrastructures réseau différentes. Notre objectif est de proposer des solutions pour intégrer la criticité mixte dans des domaines industriels hautements contraints afin de mélanger des flux de différentes criticité au sein de la même infrastructure. Cette intégration implique des contraintes d'isolation : l'impact du traffic non critique sur le traffic critique doit être borné, et le plus faible possible. C'est une condition indispensable pour assurer le respect des contraintes de temps de transmission. Afin d'analyser ces délais de transmission et de centrer notre travail sur le déterminisme de ces transmissions, nous avons recours à une méthode de calcul de délai de bout en bout appelé l'approche par trajectoires. Dans ce travail, nous utilisons une version corrigée de l'approche par trajectoires, prenant en compte la serialisation des messages.Afin d'assurer les contraintes de délais dans les réseaux à criticité mixte, nous présentons tout d'abord un modèle théorique d'intégration de la criticité mixte. Ce modèles est issu de l'ordonnancement temps-réel en contexte processeur. Ce modèle présente une modélisation des flux considérant que chaque flux peut être de plusieurs niveaux de criticité.Pour intégrer la criticité mixte dans les réseaux temps-réel, nous proposons deux protocoles différents. Le premier est le protocole centralisé. Il est organisé autour de la désignation d'un noeud central dans le réseau, responsable de la synchronisation des niveaux de criticité de chaque noeud via a un mécanisme d'émission multiple fiable. Ce mécanisme est chargé de faire changer les niveaux de criticité de tous les noeuds au même instant. Le second protocole est basé sur une approche distribuée. Il propose une gestion locale à chaque noeud de la criticité. Chaque noeud gère individuellement son propre niveau de criticité interne. Ce protocol permet de préserver les transmissions d'une part du traffic non critique au sein du réseau, même en parallèle de transmissions de flux critiques.Afin de proposer une implémentation de ces protocoles dans Ethernet, nous détaillons comment réutiliser la marque de l'en-tête de Ethernet 802.1Q pour spécifier le niveau criticité d'un message directement au sein de la trame. Grâce à cette solution, chaque flux du réseau est marqué de son niveau de criticité et cette information peut être décodée par les noeuds du réseau afin d'opérer un ordonnancement en conséquence. De plus, en gestion centralisée, nous proposons une solution permettant d'intégrer les informations de gestion de la criticité directement dans les trames du protocole de synchronization d'horloge gls{PTP}.Durant notre travail, nous avons conçu un outil de simulation dénommé gls{ARTEMIS}. Cet outil est utilisé pour l'analyse de délais de transmission dans des réseaux temps-réel et pour l'analyse de scénarios d'ordonnancement à criticité mixte. Les résultats de simulation obtenus nous permettent de formuler différentes hypothèses sur les garanties de qualité de service offertes par les protocoles centralisé et décentralisé. En termes de transmission de trafic non critique, le protocole décentralisé permet d'assurer la transmission d'une certaine quantité de messages grâce au fait que certains noeuds du réseau soient resté en mode non-critique.Pour conclure, nous proposons des solutions d'intégration de la criticité mixte à la fois dans des contextes industriels lourds et dans des architectures Ethernet grand public. Les solutions proposées peuvent être à la fois adaptées à des réseaux synchronisés ou non synchronisés. Selon le protocole, la configuration individuelle à appliquer à chaque noeud peut être réduite afin de proposer des solutions implémentables sur du matériel moins coûteux / MC (Mixed-Criticality) is an answer for industrial systems requiring different network infrastructures to manage informations of different criticality levels inside the same system. Our purpose in this work is to find solutions to integrate gls{MC} inside highly constrained industrial domains in order to mix flows of various criticality levels inside the same infrastructure. This integration induces isolation constraints : the impact of non-critical traffic on critical traffic must be characterized and bounded. This a condition to respect timing constraints. To analyze transmission delays and focus on the determinism of transmissions, we use an end-to-end delay computation method called the trajectory approach. In our work, we use a corrected version of the trajectory approach taking into account the serialization of messages.To assure the respect of timing constraints in mixed critical networks, we first present a theoretical model of gls{MC} representation. This model is issued from gls{MC} tasks scheduling on processors. This model proposes a flow modelization which considers that each flow can be of one (low critical flows) or several criticality levels.To integrate gls{MC} inside gls{RT} networks, we propose two network protocols. The first is the centralized protocol. It is structured around the definition of a central node in the network, which is responsible for synchronizing the criticality level switch of each node through a reliable multicast protocol in charge of switching the network criticality level. This centralized protocol proposes solutions to detect the needs to change the criticality levels of all nodes and to transmit this information to the central node. The second protocol is based on a distributed approach. It proposes a local gls{MC} management on each node of a network. Each node individually manages its own internal criticality level. This protocol offers solutions to preserve when possible non-critical network flows even while transmitting critical flows in the network through weak isolation.In order to propose an implementation of these protocols inside Ethernet, we describe how to use Ethernet 802.1Q header tag to specify the criticality level of a message directly inside the frame. With this solution, each flow in the network is tagged with its criticality level and this information can be analyzed by the nodes of the network to transmit the messages from the flow or not. Additionnally, for the centralized approach, we propose a solution integrating gls{MC} configuration messages into gls{PTP} clock-synchronization messages to manage criticality configuration information in a network.In this work, we designed a simulation tool denoted as gls{ARTEMIS} (Another Real-Time Engine for Message-Issued Simulation). This tool is dedicated to gls{RT} networks analysis and gls{MC} integration scheduling scenarios. This tool, based on open and modular development guidelines, has been used all along our work to validate the theoretical models we presented through simulation. We integrated both centralized and decentralized protocols inside gls{ARTEMIS} core. The obtained simulations results allowed us to provide information about the gls{QOS} guarantees offered by both protocols. Concerning non-critical traffic : the decentralized protocol, by permitting specific nodes to stay in non-critical nodes, assures a highest success ratio of non-critical traffic correct transmission.As a conclusion, we propose solutions to integrate gls{MC} inside both industrial and gls{COTS} Ethernet architectures. The solutions can be either adapted to clock-synchronized or non clock-synchronized protocols. Depending on the protocol, the individual configuration required by each switch can be reduced to adapt these solutions to less costly network devices
|
Page generated in 0.0565 seconds