Discussion:Isolation des systèmes temps réel

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Article de qualité
  • Bon article
  • Lumière sur
  • À faire
  • Archives
  • Commons

Salut. Un utilisateur a renommé la discussion, l'intitulé était pourtant conforme à ce que nous avait présenté Gilles Grimaud. De ce fait je reporte le titre directement dans la discussion, et je ferai de même pour toutes mes relectures, classées par dates décroissantes.

Relecture de Edouard Delbar le 4 Février 2018[modifier le code]

Globalement je pense qu'il faut retravailler le plan. En l'état l'article est assez décousu, on ne perçoit pas le lien entre les différentes sections, c'est plutôt une énumération de techniques. J'aimerais vous faire une proposition mais je n'ai pas encore avancé sur ce sujet.

Systèmes à criticités mixtes[modifier le code]

Le titre est au pluriel, je crois qu'on utilise plutôt le singulier lorsque l'on parle de systèmes à criticité mixte. --Edouard DELBAR (discuter) 4 février 2018 à 17:26 (CET)[répondre]
Modifications prises en compte. PierreCaruyer (discuter) 11 février 2018 à 08:33 (CET)[répondre]

Définition[modifier le code]

Dans la phrase "sans qu'il soit nécessaire de prévoir les cas particuliers", pourriez vous préciser de quels cas particuliers il s'agit ? J'ai cherché dans la page donnée en référence (http://dx.doi.org/10.1109%2FRTCSA.2014.6910550, p1), je n'ai pas retrouvé cette idée. Faites vous référence à cette phrase "The latter issue [interference between applications] forces designers to assume the worst case latency for every individual memory transaction" ? --Edouard DELBAR (discuter) 4 février 2018 à 17:26 (CET)[répondre]
Cette partie de la définition fait plus référence à la conception d'un framework d'isolation. PierreCaruyer (discuter) 11 février 2018 à 08:33 (CET)[répondre]
Pourriez-vous préciser comment un niveau de confiance hétérogène permet d'éviter la propagation des erreurs ? Je crains que le lien implicite entre le niveau de confiance et la propagation des erreurs soit difficile à percevoir et introduise de la confusion dans la définition générale. --Edouard DELBAR (discuter) 4 février 2018 à 17:26 (CET)[répondre]
Ici, ce que nous avons essayé d'expliquer, c'est qu'à chaque processus est attribué un niveau de criticité qui correspond un niveau de confiance que ce processus se doit de respecter : plus le niveau de criticité de ce processus sera élevé, plus cela signifie que la confiance que l'on attribue à ce processus est forte et donc que ce processus doit terminer son exécution dans un intervalle court, par exemple. Mais surtout, plus le niveau de criticité sera élevé, plus on aura besoin que ce processus soit isolé des autres processus et moins il doit avoir de chance d'être corrompu par les erreurs des autres processus. PierreCaruyer (discuter) 8 février 2018 à 06:45 (CET)[répondre]
Dans la phrase "Un processus dans un système à criticités mixtes se distingue des autres systèmes par des paramètres spécifiques", on pourrait croire que vous comparez "un processus" avec "les autres systèmes". Que pensez-vous de la remplacer par la phrase "Un processus dans un système à criticités mixtes se distingue d'un processus dans les autres types de systèmes par des paramètres spécifiques" ? --Edouard DELBAR (discuter) 4 février 2018 à 17:26 (CET)[répondre]
En effet, ça éviterait les confusions. On va changer ça. PierreCaruyer (discuter) 7 février 2018 à 08:20 (CET)[répondre]
Il y a deux liens externes vers la définition du temps d'exécution dans le pire des cas, et le second pointe vers une archive qui donne un résultat à peu de choses près identique au premier, à mon avis il faudrait en retirer au moins un. J'irais même plus loin, il n'est peut-être pas nécessaire d'en donner la définition, il me semble que c'est une notion suffisamment intuitive, en particulier pour un public d'informaticiens.--Edouard DELBAR (discuter) 4 février 2018 à 17:26 (CET)[répondre]
C'est une notion qui en effet assez simple mais qui, je pense, reste intéressante car il couvre plusieurs domaines du temps réel. Par ailleurs les liens externes n'en donnaient qu'une définition succinte, les deux liens ont été remplacés par un lien vers un article wikipedia assez complet sur le sujet qui mériterait d'être lu par qui serait intéressé par le sujet.PierreCaruyer (discuter) 8 février 2018 à 06:43 (CET)[répondre]

Problématiques[modifier le code]

À mon avis il serait bon d'annoncer les deux sous-titres ("Partage & partitionnement" et "Délai d'accès aux ressources") dans l'introduction de la section "Problématiques" pour faire la transition. En l'état j'ai peur que l'introduction soit exposée de manière trop brutale pour le lecteur, la phrase ne laisse pas deviner un développement futur. Par ailleurs ça permettrait de justifier implicitement l'utilisation du pluriel dans le titre de la section ("Problématiques"). Par exemple, on pourrait ajouter "Le temps d'exécution dépend notamment du partage et du partitionnement des ressources, ainsi que du délai d'accès aux ressources." --Edouard DELBAR (discuter) 4 février 2018 à 17:27 (CET)[répondre]
D'accord, en effet cela rendrait plus lisible les deux sous-parties de la partie "problématiques" ainsi que de l'article . PierreCaruyer (discuter) 12 février 2018 à 23:48 (CET)[répondre]
À mon avis le titre est trop court, et il manque une introduction succincte à cette section pour définir le cadre du sujet. Plus bas dans l'article je vois que vous parlez également de sécurité, dès lors le lecteur peut se demander quelle différence il y a entre sûreté et sécurité, et pourquoi l'isolation temporelle est liée au thème de la sûreté, tandis que l'isolation mémoire est liée au thème de la sécurité. Vous ne dites pas non plus à quoi s'appliquent ces deux notions (sûreté et sécurité du système en général, de l'accès aux ressources, etc... ?). --Edouard DELBAR (discuter) 4 février 2018 à 18:35 (CET)[répondre]
Nous avons rajouté un lien vers l'article principal et nous allons définir la notion de sûreté en début de partie. PierreCaruyer (discuter) 12 février 2018 à 23:48 (CET)[répondre]

Isolation temporelle[modifier le code]

Systèmes à criticité mixte et isolation temporelle[modifier le code]

Vous dites "les tâches Ti sont définies par une période (la fréquence d'exécution)", or la période est la durée d'un phénomène répétitif, tandis que la fréquence correspond au nombre de répétitions de ce phénomène pendant un intervalle de temps donné. Il me semble que ce sont deux concepts différents, on ne peut donc pas dire "période égal fréquence". De plus, l'article que vous citez désigne une tâche par le symbole grec "τ", et la période par la lettre "T", il me semble que vous faites l'amalgame. --Edouard DELBAR (discuter) 4 février 2018 à 17:59 (CET)[répondre]
C'est vrai que cette formulation laisse à désirer, nous allons retravailler dessus pour qu'elle soit plus proche de ce qui définit réellement la période d'une tâche. PierreCaruyer (discuter) 11 février 2018 à 08:33 (CET)[répondre]

Sécurité[modifier le code]

Vous pouvez vous référer aux remarques faites plus haut sur la section "Sûreté". Je remarque que la section "Sécurité" n'a qu'une seule sous-section, "Isolation mémoire", cela veut-il dire que la sécurité est entièrement définie par l'isolation mémoire ? Si tel est le cas, il pourrait être utile de fournir quelques explications au lecteur. --Edouard DELBAR (discuter) 4 février 2018 à 18:43 (CET)[répondre]
Nous avons rajouté un lien vers l'article principal et nous allons définir la notion de s en début de partie. PierreCaruyer (discuter) 12 février 2018 à 23:48 (CET)[répondre]

Futur des systèmes à criticité mixte[modifier le code]

Il serait peut-être judicieux d'intégrer cette section à la section "Systèmes à criticité mixte", en particulier à la sous-section "Problématiques". Par ailleurs je doute qu'il soit nécessaire de parler au futur sachant que la recherche est déjà active sur le sujet. Si j'ai bien compris on parle de l'actualité récente et non d'un avenir lointain et incertain. --Edouard DELBAR (discuter) 4 février 2018 à 18:57 (CET)[répondre]
La formulation porte à confusion, en effet, ce sont des recherches qui commencent et qui vont s'intensifier d'après la review de burns et davis. Nous allons modifier ce paragraphe pour rendre plus clair que ce sera bien un domaine de recherche à l'avenir. PierreCaruyer (discuter) 12 février 2018 à 23:48 (CET)[répondre]
Vous dites "De nombreuses recherches sont actuellement menées", pourriez-vous citer quelques exemples ? --Edouard DELBAR (discuter) 4 février 2018 à 18:58 (CET)[répondre]
Le paragraphe a été modifié.

Architectures distribuées[modifier le code]

Relecture de Edouard Delbar le 22 Janvier 2018[modifier le code]

Introduction[modifier le code]

Pour commencer voici quelques remarques au niveau de la forme.

Il y a une forme de pléonasme dans "L'isolation des systèmes temps réel est une pratique de plus en plus utilisée dans les systèmes temps réel .". On le voit bien si on retire une partie de la phrase, "L'isolation des systèmes temps réel est [...] utilisée dans les systèmes temps réel.".

Introduction maladroite : Merci pour cette précision. Nous allons revoir avec Pierre l'introduction. --MaximeRoelandt (discuter) 22 janvier 2018 à 14:34 (CET)[répondre]
Après discussion avec Gilles Grimaud, il semblerait que l'isolation soit utilisée précisément dans le cadre des systèmes à criticité mixte. Si c'est le cas c'est uniquement un problème de formulation, il suffit peut-être d'ajouter quelques précisions. --Daroud (discuter) 22 janvier 2018 à 17:35 (CET)[répondre]
J'ai lu la nouvelle version de l'introduction, je trouve ça beaucoup plus clair. Par contre, si j'ai bien compris les explications de Gilles Grimaud, la criticité mixte désigne la diversité des aspects critiques du système (espace, temps, etc...) plutôt que les degrés de criticité des tâches. Votre nouvelle version laisse penser le contraire. --Daroud (discuter) 22 janvier 2018 à 18:08 (CET)[répondre]
J'ai changé la première phrase pour l'instant. Nous allons retravailler la suite. Merci pour ta remarque. --MaximeRoelandt (discuter) 23 janvier 2018 à 09:35 (CET)[répondre]
Ensuite il y a une répétition, on pourrait remplacer "Dans un système à criticités mixtes, au moins deux niveaux de criticité sont présents : critique et non-critique. Dans un système à criticités mixtes, plus une tâche a un niveau de criticité élevé, plus les contraintes sur cette tâche seront fortes." par "Dans un système à criticités mixtes il y a au minimum deux niveaux de criticité, critique et non-critique, et plus le niveau de criticité d'une tâche est élevé, plus les contraintes sur cette tâche seront fortes.". Pour finir, l'utilisation du présent et du futur dans la même phrase ça ne marche pas très bien. On pourrait remplacer "plus le niveau de criticité d'une tâche est élevé, plus les contraintes sur cette tâche seront fortes." par "plus le niveau de criticité d'une tâche est élevé, plus les contraintes sur cette tâche sont fortes.".
Changements effectués, ce sera plus clair comme ça, merci pour les précisions. --Pierre Caruyer (discuter) 22 janvier 2018 à 13:20 (CET)[répondre]

C'est tout pour la forme. Je poursuis avec quelques remarques concernant le fond.

Il faudrait peut-être préciser de quel type d'isolation on parle et en donner une définition succincte. En l'occurrence le lien mène vers une page traitant de l'isolation dans le domaine des bases de données (Isolation_(informatique)), avez-vous pensé à l'isolation dans le domaine de la virtualisation (https://doc.fedora-fr.org/wiki/Virtualisation#D.C3.A9finition_de_la_virtualisation)? Ensuite, le sujet principal a tendance à s'effacer derrière le sujet des systèmes à criticité mixte (attention au singulier), pourtant vous dites que les systèmes à criticité mixte sont un sous-ensemble des systèmes temps réel (confirmé ici : https://fr.wikipedia.org/wiki/Criticit%C3%A9_mixte). Concrètement, si on ne regarde que l'introduction, il semblerait plus cohérent d'intituler l'article "Isolation des systèmes à criticité mixte".
En effet, le résumé introductif manquait de définitions, notamment sur l'isolation, les systèmes temps réel, les systèmes à criticité mixte etc... Au niveau du titre de l'article, nous avons fini par nous concentrer sur les systèmes à criticité mixte, il serait donc effectivement plus approprié d'utiliser le terme "systèmes à criticité mixte" dans le titre au lieu de "systèmes temps réel"

--Pierre Caruyer (discuter) 22 janvier 2018 à 13:20 (CET)[répondre]

Mixed Criticality Systems regroupe deux notions : la partie temps réelle et l'isolation mémoire. Notre article : Isolation des systèmes temps réel fait référence à l'isolation spatiale et temporelle. L'isolation temporelle garantit le temps de réponse du système temps réel, l'isolation mémoire quant à elle correspond à l'isolation spatiale. Il semble que l'article ne précise pas assez la notion de Mixed Criticality Systems dans l'introduction et peut être dans la suite de l'article. Merci pour vos recommandations, nous allons effectuer les modifications nécessaires. --MaximeRoelandt (discuter) 22 janvier 2018 à 17:16 (CET)[répondre]

Voici quelques questions que le lecteur pourrait se poser après avoir lu l'introduction :

  • Qu'est-ce que l'isolation ? À quoi elle s'applique ? (OS, applications, mémoire, transactions, etc...)
  • Qu'est-ce que l'isolation des systèmes temps réel ?
  • En quoi se différencie-t-elle de l'isolation des autres systèmes ?
  • Qu'est-ce que l'isolation des systèmes à criticité mixte ?
  • En quoi se différencie-t-elle de l'isolation des autres systèmes temps réel ?
La première source "Mixed Criticality Systems - A Review" ne semble pas correctement renseignée. "Dep. Computer Science" n'est pas un périodique, c'est le nom du département de l'université de York à l'origine de l'article ("Department of Computer Science, University of York, York, UK"). La source elle-même (résultat Google : https://www-users.cs.york.ac.uk/burns/review.pdf) est probablement une relecture (non officielle : https://www-users.cs.york.ac.uk/) d'un article publié dans l'ACM Computing Surveys :
Merci de d'avoir pointé du doigt cet oubli, c'est corrigé :) --Pierre Caruyer (discuter) 22 janvier 2018 à 13:20 (CET)[répondre]