In the previous Visum version of line blocking, the blocks always had to be correct, which means that they were not allowed to have time or location breaks. The result was, that the blocks were deleted when making important changes in the network (for example at vehicle journeys). This cannot be tolerated, especially when blocks were edited manually and therefore cannot simply be restored by carrying out line blocking again. In the block data model now available in Visum, the consistency of line blocks with the network is assured and in return the constant correctness of the block itself is no longer required. Instead, you have the possibility of performing a check line block to calculate the status which codes the information on consistency (called error flags below) for each block. These error flags provide you with information on whether the blocks are error free and if not, in which respect there are inconsistencies. All together there are eight error flags.
The state model in Image 190 shows the possible state transitions of a block and how the eight error flags are set.
Image 190: State model for line blocks
The blocks react if the network database changes. Changes to the block version, the block items and the vehicle journey sections are taken into consideration. Moreover, blocks react to changes made to the basic network settings, in particular to calendar settings.
- Location fault
Two successive trips in a block do not match, because the successive trip does not start at the same stop point, where the preceding trip ends.
- Time fault
Two successive trips in a block overlap with regard to time. This means, that the preceding trip arrives later than the successive trip departs.
- Layover time fault
Two successive trips overlap each other in time only if for arriving trips the post-preparation time and for departing trips the pre-preparation time is included in a block. This means, that the planned layover time is not sufficient. In practice such an error can be ignored sometimes, but has to be checked manually. If both trips are connected by forced chaining, adherence to the pre- and post preparation time is not checked for this transfer, because the forced chaining has priority.
- Vehicle fault
The block includes vehicle journey sections to which a vehicle combination was allocated which does not match the block. This error can occur if, for example, line blocking has calculated a block for a standard bus and later on the user manually assigns a low-floor bus to one of the trip sections. The attribute Has vehicle interchange is used for the evaluation of this error. This decides whether the comparison regards either vehicle journey section attribute vehicle combination or vehicle combination set.
- Blocking day error (EmptyDayFault)
If there is an empty blocking day, this error is set. This means, that there is a blocking day without a block item on any calendar day (except for layover items). In this case, an extra vehicle has unnecessarily been planned.
- Limit fault
This error only occurs when user-defined block items are used. An error flag is shown if the defined minimum state of charge is not reached within a block or when the defined time or length limit values are exceeded.
- Forced chaining fault
In the block there is a vehicle journey section, which is the starting point of a valid forced chaining, which however is not realized in the block. The vehicle journey section successor is therefore not the destination vehicle journey section of the forced relation.
- Direction fault
The line block includes a vehicle journey section which is serviced in the opposite direction on a different day, or the vehicle's direction of travel changes after a closed line block has been completed. This error is only checked if the line block attribute Regard running direction is true at the line block.
A block that contains the flag unchecked or time fault or location fault is not allowed to be regarded by subsequent evaluations (for example in the PuT operating indicators procedure). The other six flags however, do not restrict usability. This is necessary to be able to transfer plans from other systems and use them for line performance and line costing calculations in the procedure PuT operational indicators (PuT interlining matrix procedure), which often contains such errors (partially deliberately).
Common and forced line block check
Between the network basis and blocks, two types of inconsistencies can occur through subsequent changes, which are not found in common checks of line blocks. To check consistency in all respects, you can carry out the so-called forced check (User Manual: Performing the line block check). These are the two inconsistencies in detail:
- When using reduced layover times, it could occur that no error flag is displayed, although the block contains a layover time error (LayoverTimeFault). This is the case if the value of one of the three attributes describing the reduced layover time was subsequently edited or the selection of one of these attributes changed. These user-definable attributes of stop points and vehicle journey sections are: reduced pre-preparation time, reduced post-preparation time and maximum dwell time. The reason for this is that these three attributes can be specified dynamically by the user (in particular, also indirect or user-defined attributes can be used). Due to calculation times, it is not efficiently possible to react to changes in these attributes and to automatically set the error flag. That is why you have to carry out the forced version of the check line block, to make sure that all layover time undershoots (layover time fault) are determined in the checked blocks if subsequent changes have been made. If no reduced layover times are used (block version property), this problem can not occur.
- Subsequent changes to the network do not cause automatic adjustments of potentially concerned empty trips (for example when changing PuT run times of links or when blocking links for a PuT transport system). Location and time faults can thus remain undiscovered. Also in this case, it is - for calculation time reasons - not possible, that line blocks react to network changes. This is why only a forced check can assure that the blocks do not contain such errors if the network used by empty trips has been changed subsequently.
