Vérification des rotations
Dans le calcul des rotations de versions antérieures de Visum, les rotations devaient toujours être correctes et ne devaient par exemple ni présenter d’erreurs temporelles ni d’erreurs d’emplacement. Ceci entraînait la suppression des rotations lors de modifications majeures dans le réseau (par exemple pour les services). Ceci est particulièrement intolérable lorsqu’un planificateur doit modifier les rotations manuellement et qu’elles ne peuvent pas être simplement reproduites en exécutant à nouveau le calcul des rotations. Dans le modèle de données de rotations désormais disponible dans Visum, la cohérence des rotations par rapport au réseau est assurée et il n’est ainsi pas indispensable que la rotation soit correcte à tout moment. Au contraire, vous avez la possibilité de calculer un état avec des informations sur la cohérence (désigné ci-après par indicateur d’erreur) pour chaque rotation à l’aide de la vérification des rotations. Ces indicateurs d’erreur vous indiquent si les rotations sont sans erreur et dans quel domaine il existe des incohérences dans le cas contraire. Il existe huit indicateurs d’erreur.
Le modèle d’état dans l’Illustration 196 montre les changements d’état possibles d’une rotation et comment les huit indicateurs d’erreur sont appliqués.
Illustration 196 : Modèle d’état pour les rotations
Lorsque la base du réseau est modifiée, ces modifications se répercutent sur les rotations. Les modifications du résultat de rotation, des éléments de rotation et des sections de service sont prises en considération. En outre, les modifications de la configuration du réseau fondamentale se répercutent aussi sur les rotations, notamment les modifications du calendrier.
- Erreur d’emplacement (LocationFault)
Deux services successifs d’une rotation ne coïncident pas, car le service suivant ne commence pas au même point d’arrêt que celui où finit le service précédent.
- Erreur temporelle (TimeFault)
Deux services successifs dans une rotation se chevauchent dans le temps. Cela signifie que le service précédent arrive plus tard que le service suivant ne démarre.
- Erreur de temps d’arrêt technique (LayoverTimeFault)
Deux services successifs dans une rotation ne se chevauchent dans le temps que lorsqu’on tient compte du temps de préparation Post pour le service qui arrive et du temps de préparation Pré pour le service qui démarre. Cela signifie que le temps de rebroussement prévu n’est pas suffisant. Dans la pratique, on peut parfois ignorer une telle erreur, à condition de vérifier manuellement. Si les deux services sont associés par un chaînage forcé, le respect des temps de préparation Pré et Post n’est pas vérifié pour cette transition car le chaînage forcé l’emporte.
- Erreur de véhicule (VehicleFault)
La rotation contient des sections de service auxquelles une combinaison de véhicules qui ne coïncide pas avec la rotation a été assignée. Cette erreur peut par exemple survenir lorsque le calcul des rotations a déterminé une rotation pour un bus standard et que vous assignez par la suite un bus articulé manuellement à une des sections de service. L’attribut Avec échange de véhicules est pris en considération lors de l’évaluation de cette erreur. Il détermine si l’attribut de section de service NumCombinaisonVéh ou Ensemble CombinaisonVéh doit être utilisé pour l’ajustement.
- Erreur de jour de rotation (EmptyDayFault)
Cette erreur survient lorsqu’il existe un jour de rotation vide. Cela signifie qu’il existe un jour de rotation pour lequel aucun élément de rotation (à l’exception des éléments d’arrêt) n’est situé dans un jour du calendrier. Il résulte de cette erreur qu’un véhicule de trop a été prévu.
- Erreur de seuil (LimitFault)
Cette erreur se produit uniquement quand il existe des éléments de rotation définis par l’utilisateur. Cet indicateur d’erreur stipule que l’état de chargement minimum défini au sein d’une rotation n’est pas atteint ou que les seuils de durée ou de longueur sont dépassés.
- Erreur de chaînage forcé (ForcedChainingFault)
Il existe une section de service dans la rotation qui est le point de départ d’un chaînage forcé valide mais qui n’est pas réalisé dans la rotation. Le successeur de cette section de service dans la rotation n’est donc pas la section de service de destination du chaînage forcé.
- Erreur de sens de circulation (DirectionFault)
Dans la rotation, il existe soit une section de service desservie en sens de circulation inverse pour différents jours, soit le sens de circulation du véhicule change après un cycle complet de la rotation dans le cas d’une rotation fermée. Cette erreur est uniquement vérifiée lorsque l’attribut Tenir compte de sens de circulation est vrai pour la rotation.
Lorsqu’une rotation comporte les indicateurs non vérifié ou une erreur temporelle ou d’emplacement, elle ne peut être utilisée pour les évaluations ultérieures (par exemple la procédure Indicateurs d’exploitation TC). Les autres six indicateurs ne restreignent pas la possibilité d’utiliser une rotation. Ceci est nécessaire pour pouvoir appliquer des planifications issues d’autres systèmes qui contiennent souvent de telles erreurs (en partie délibérément) et les utiliser pour le calcul de rendement des lignes dans la procédure Indicateurs d’exploitation TC (Description de la procédure Matrice de transferts TC).
Vérification des rotations ordinaire et forcée
Des modifications du réseau ultérieures peuvent entraîner deux types d’incohérence entre la base du réseau et les rotations, qui ne sont pas identifiées dans la vérification des rotations ordinaire. Afin de vérifier la cohérence à tout point de vue, on peut aussi effectuer une vérification dite forcée (Utilisation : Exécuter la vérification des rotations). Les deux incohérences pouvant survenir sont les suivantes :
- Lorsqu’on utilise des temps de rebroussement plus courts, il peut arriver qu’une rotation ne présente pas d’indicateur d’erreur bien qu’elle contienne une erreur de temps d’arrêt technique (LayoverTimeFault). C’est le cas lorsqu’on a modifié ultérieurement une valeur dans les trois attributs décrivant le temps de rebroussement plus court (attributs du point d’arrêt ou de la section de service spécifiés par l’utilisateur pour le temps de préparation Pré raccourci, le temps de préparation Post raccourci et la durée d’arrêt maximale) ou qu’on a modifié la sélection d’un de ces attributs. Ceci provient du fait que vous pouvez spécifier ces trois attributs de manière dynamique (en particulier, vous pouvez aussi utiliser des attributs indirects ou définis par l’utilisateur). Pour des raisons de temps de calcul, il n’est pas possible de réagir de manière efficace aux modifications de ces attributs et d’appliquer l’identifiant d’erreur automatiquement. C’est la raison pour laquelle vous devez effectuer la variante forcée de la vérification des rotations pour vous assurer que toutes les erreurs de temps de rebroussement (erreur de temps d’arrêt technique) sont détectées dans les rotations vérifiées lorsque des modifications ultérieures ont eu lieu. Ce problème ne peut survenir lorsqu’on utilise des temps de rebroussement raccourcis (propriété du résultat de rotation).
- Des modifications ultérieures dans le réseau n’entraînent pas l’ajustement de services éventuellement concernés (par exemple lors de la modification de temps de parcours TC sur les tronçons ou lors de l’interdiction de tronçons à un système de transport TC). Même des erreurs d’emplacement ou temporelles peuvent ne pas être détectées. Pour des raisons de temps de calcul, aucune réaction des rotations n’est possible ici non plus par rapport aux modifications du réseau. Seule une vérification forcée permet donc de s’assurer que de telles erreurs ne sont pas contenues dans les rotations lorsque le réseau utilisé pour les services à vide a été modifié après coup.