Options
Introduction
On this page, we provide a list of the key thresholds and constants that can be customised for a specific client or network. We also provide a description of the influence that each parameter is likely to have on the model output.
The constants and thresholds listed in this section are generally defined in the model Lookup Tables. A set of Default Lookup tables assigned to the Domain Model can be used, or alternatively some or all of the default Lookup Tables can be over-ridden at the Project Level. For more information about the defining Project level data, please [refer to this documentation]https://lonrix-limited.github.io/jcass_docs2/config_data/project_setup_data.html).
Note that Options discussed below are by default suited for New Zealand roads. If you are using Cassandra in another country you may find that some of the terminology does not apply directly to your situation. However, this can be easily addressed through minor modifications of your model and/or by modifying the values imported into your input set during the pre-processing stage.
Talk to Lonrix Ltd or ASC Ltd if you need help in configuring your model using the lookup options discussed below.
Treatment Selection
The different Treatment Types and the logic for Treatment Selection is discussed in this section and this section.
The following table shows some of the thresholds and constants that can be modified on a network-by-network basis to calibrate the model for a specific environment:
Treatment Suitability Scores
Treatment Suitability Scores (TSS’s) are used in the Multi-Criteria Decision Analysis (MCDA) method to determine the relative suitability for each treatment type on a candidate segment. The following table shows some of the options that can be modified at the project/network level to adjust the Treatment Suitability Scores:
Pavement Expected Life
Pavement Expected Life is an important factor that influences, at each modelling period, how many years of pavement life remains. The pavement remaining life, in turn, will influence aspects such as Rut Rate, Roughness Rate and the probability of various distresses occurring.
If Multi-Speed Deflectometer (MDS) data is available and pavement remaining life has been assigned based on this data, then the initial Pavement Expected Life will be known. Initial Pavement Expected Life can also be assigned in the model input file through a pre-processing algorithm.
However, after Rehabilitation treatments are applied, the initial pavement expected life is no longer valid and a reset has to be applied. The table below shows the Pavement Expected Life values lookup applied after Rehabilitation OR applied during initialisation if an initial estimate is not available (e.g. from MSD data)
Distress Initialisation and Progression
It was explained in an earlier section that Visual Distresses such as Flushing, Mesh Cracks and Potholes are modelled using the S-Curve model. For this model type, the three key parameters (AADI, T100 and Initial Value) can be constrained within a certain minimum and maximum range. These limits ensure that the model is stable and will always generate progression curves that are within practical and expected ranges.
The table below shows some of the limits and thresholds that can be modified at the Project/Network level to calibrate or adjust distress progression for your network:
Pre-Seal Repair Costs
As explained in the section dealing with Treatment Types, the model allows for Pre-Seal Repairs on both Seals and Asphalts. In the latter case the repairs are better named ‘Pre-Paving Repairs but for conciseness we use the term ’Pre-Seal Repairs’ for both AC and Chipseals.
When the model evaluates a Pre-Seal Repair treatment during the BCA-or-MCDA optimisation methods, it will dynamically calculate an estimated Pre-Seal repair cost based on the extent of distress that is present. This calculation is a two-stage process:
- First we convert the extent of Pavement-related distress (expressed by the Pavement Distress Index, or PDI) to a fraction of the segment area. Table 5 below shows how this conversion is done. The values in this table can be modified for each network based on local experience and judgement.
- Once the fraction of the segment area to be repaired is known, this quantity needs to be multiplied by a unit rate for Pre-Seal repairs in order to get an estimated cost for Pre-Seal repairs. Table 6 below shows how this unit rate can be specified on the basis of surface type (Seal or AC) and the traffic level.
The Cassandra model thus allows for fine grained control over how you want to estimate the cost of Pre-Seal repairs on your network.
Expected Surfacing Life
In the sections detailing how the S-Curve model for distress estimation works it was noted that the Age at Distress Initiation (AADI) is estimated on the basis of the Expected Surfacing Life, coupled with the Probability of distress occuring on the specific segment.
Thus, the Expected Surface Life plays a crucial role in calibrating the S-curve models for each network. Expected Surface Life, as the name implies, is simply the number of years that different surfacing types are expected to last.
Experienced network managers will typically have a good idea of what life can be expected from different types of surfacings in different scenarios. Alternatively, historical surfacing records can be analysed to determine the typical “achieved life” of surfacings before they are replaced or resealed/overlaid.
In the Cassandra Model, the starting or initial Expected Surface Life needs to be pre-assigned in the input file as part of pre-processing. However, this Expected Life needs to be replaced during the model run whenever a treatment is applied. To do this, Table 7 is used as a lookup.
In Table 7, the key shown in the ‘setting_key’ column is a concatenation as follows (not applicable to the first 4 rows which are fall-through values):
[surface function][surface_type][traffic_class]
Thus a code such as ‘R_AC_M’ denotes a segment that has a Reseal (code ‘R’) surface function, an ‘AC’ surface type and a ‘Medium’ (code ‘M’) traffic class.
The values shown in Table 7 for expected lives are an important part of model calibration for a specific network, and therefore has to be carefully discussed with the client and finalised before modelling commences.
Assignment of Traffic Classes
It was noted in the sections above (e.g. those dealing with Expected Surface Life and Expected Pavement Life) that traffic class plays an important role in certain lookup tables. Currently, the default model uses groupings of ‘Low’, ‘Medium’ and ‘High’ with associated codes ‘L’, ‘M’ and ‘H’.
As shown in Table 8 below, in the default model the traffic classes are assigned on the basis of a Road Classification code (in New Zealand, this is typically the One Network Road Classification, or ONRC). If you prefer to assign road class based on some other measure, you can modify the input file and the lookup table shown below.
