JunoViewer Web User Guideline Ver 2

JunoViewer Web Framework
Technical Guideline
Version 2
Feb 2015
Prepared For: Prepared By:

Lonrix Ltd Juno Services Limited
11 Driver Road West, RD1 11 Driver Road West, RD1
Hamilton Hamilton
New Zealand New Zealand
Email: info@junoviewer.com
Web: www.junoviewer.com
i
JunoViewer Web Framework Technical Guideline Table Of Contents
Table of Contents
1. Introduction.............................................................................................................................. 1
1.1. What is in this Guideline?.................................................................................................. 1
1.2. What is JunoViewer Web? ................................................................................................ 1
1.3. How to use this Guideline.................................................................................................. 2
1.4. Our Sidebars .................................................................................................................... 2
1.5. Stay Updated! ................................................................................................................... 3
2. Key Definitions......................................................................................................................... 4
2.1. Network ............................................................................................................................ 4
2.2. Section ............................................................................................................................. 4
2.3. Segment ........................................................................................................................... 4
2.4. Treatment Length ............................................................................................................. 4
2.5. Modelling Segment ........................................................................................................... 5
2.6. Segment Group ................................................................................................................ 5
2.7. Lane Segments................................................................................................................. 5
2.8. Forward Works Programme .............................................................................................. 5
2.9. Segment Set ..................................................................................................................... 6
2.10. Data Join Parameter ......................................................................................................... 6
2.11. Table Link ......................................................................................................................... 6
2.12. Long Running Processes (LRPs) ...................................................................................... 6
2.13. Point Data......................................................................................................................... 6
2.14. Segment Data................................................................................................................... 6
3. Overview of the Menu System................................................................................................. 8
3.1. Views menu ...................................................................................................................... 9
3.2. Data menu ...................................................................................................................... 12
3.3. Settings Menu ................................................................................................................. 14
3.4. Tools Menu ..................................................................................................................... 15
4. Forecast View......................................................................................................................... 17
4.1. Using Forecast View ....................................................................................................... 18
5. Deterioration Model Pre-Processing ..................................................................................... 19
5.1. Creation of Lane Segments from Lane Configuration Data .............................................. 20
5.2. Finalize Lane Segment Information ................................................................................. 23
5.3. Generate Lane-Specific Modelling Segments .................................................................. 23
5.4. Perform Data Join on Created Segments ........................................................................ 24
5.5. Fill In Missing Data on Modelling Segments .................................................................... 25
6. Deterioration Modelling – Concepts and Setup .................................................................... 28
ii
6.1. Modelling WITHOUT Assignment of Treatments ............................................................. 28

6.2. Modelling WITH Assignment of Treatments..................................................................... 28
6.3. Handling Variations within Modelling Segments............................................................... 29
6.4. Spreading Variations over a Modelling Segment ............................................................. 31
6.5. The Deterioration Model Setup File ................................................................................. 32
6.6. The Link between FWPs and Model Setups .................................................................... 32
6.7. Managing Links between FWPs and Deterioration Models .............................................. 33
6.8. Running Deterioration Models ......................................................................................... 35
6.9. Assigning Committed Treatments.................................................................................... 36
7. Deterioration Modelling with Treatment Assignment........................................................... 38
7.1. Work Sections in JunoViewer Web.................................................................................. 38
7.2. Modelling with-or-without Work Sections ......................................................................... 39
7.3. Determining WHEN and WHERE to apply treatments ..................................................... 41
7.4. The Treatment Selection Algorithm (TSA) ....................................................................... 42
7.5. Treatment Triggering Within a Segment .......................................................................... 45
7.6. Summary ........................................................................................................................ 45
8. Deterioration Modelling with Maintenance Assignment ...................................................... 47
8.1. Routine Maintenance versus Treatments ........................................................................ 47
8.2. Applying Maintenance when Modelling Variations within Segments ................................. 48
8.3. How Maintenance Cost is Determined............................................................................. 48
8.4. Implementing Routine Maintenance in your Model .......................................................... 48
9. Tools in JunoViewer Web ...................................................................................................... 50
9.1. Segment Set Creation..................................................................................................... 50
9.2. Data Join ........................................................................................................................ 51
9.3. Deterioration Rate Calculation......................................................................................... 52
The following Appendices should be downloaded as separate files:
Appendix A: Useful References – Downloadable Zip File with .PDF Documents
Appendix B: Model Setup File Reference - Separate Document
iii
List of Figures
Figure 1: Illustration of some key concepts......................................................................................... 4
Figure 2: Relationship between FWPs and Networks ......................................................................... 5
Figure 3: Outline of a typical Home Page with Main Menu .................................................................. 8
Figure 4: Example of a view to Compare Sections ........................................................................... 10
Figure 5: Example of a Dashboard view to Compare Sections ......................................................... 10
Figure 6: Example of a Stripmap Implementation ............................................................................. 11
Figure 7: Example of a Map View Implementation............................................................................ 11
Figure 8: SQL View that allows a custom select query to extract data .............................................. 12
Figure 9: Layout of the Upload/Download Data page ....................................................................... 14
Figure 10: Outline of the Forecast View display................................................................................ 17
Figure 11: Outline of the Forecast View toolbar ................................................................................ 18
Figure 12: Outline of Modelling Pre-Processing Steps ...................................................................... 19
Figure 13: Relationship between tables holding lane configurations and lane configuration types ..... 20
Figure 14: Examples of Lane Configuration Types – single carriageway roads ................................. 21
Figure 15: Examples of Lane Configuration Types – dual carriageway roads ................................... 21
Figure 16: Schematic illustration of the Lane Segments creation process ......................................... 22
Figure 17: Procedure for Handling Missing Values ........................................................................... 26
Figure 18: Example of XML Setup for Filling in Missing Values ........................................................ 27
Figure 19: Modelling without and with data aggregation ................................................................... 30
Figure 20: Modelling without and with data aggregation ................................................................... 30
Figure 21: Evening-out of model parameter values with different numbers of observations............... 31
Figure 22: Relationship between FWPs, Networks and Model Setup Files ....................................... 33
Figure 23: Page to manage Model Setups ....................................................................................... 34
Figure 24: Input form to add a new Model Setup .............................................................................. 34
Figure 25: Checking and Running a Model Setup ............................................................................ 35
Figure 26: Modelling Process Outline............................................................................................... 36
Figure 27: Format of template for defining Committed Treatments ................................................... 37
Figure 28: Illustration of the Work Section Concept .......................................................................... 38
iv
Figure 29: Assignment of treatments within a Work Section ............................................................. 39
Figure 30: Outline of the algorithm to assign treatments ................................................................... 41
Figure 31: Details of the Treatment Selection Algorithm execution ................................................... 43
Figure 32: Example of a Treatment Trigger setup with implementation in the DMS file ..................... 44
Figure 33: Model data within a segment when modelling variations within segments ........................ 45
Figure 34: Impact of Maintenance on values within a modelling segment ......................................... 48
Figure 35: Creating a Segment Set .................................................................................................. 50
Figure 36: Impact of Segment truncation.......................................................................................... 50
Figure 37: Illustration of a Data Join process.................................................................................... 51
Figure 38: Defining Data Join Parameters........................................................................................ 52
Figure 39: Calculation of Deterioration Rates ................................................................................... 53
Figure 40: Input form for calculating Deterioration Rates .................................................................. 53
Figure 41: Template for defining segments for Deterioration Rate calculation ................................... 54
Figure 42: Use of percentiles to calculate Deterioration Rates .......................................................... 54
v
List of Tables
Table 1: Sub-menu items found under the Views menu...................................................................... 9
Table 2: Sub-menu items found under the Data menu...................................................................... 13
Table 3: Sub-menu items found under the Settings menu ................................................................ 14
Table 4: User Permissions for different levels .................................................................................. 15
Table 5: Sub-menu items found under the Tools menu .................................................................... 15
Table 6: Example of Result Set in tblJoinSegments ......................................................................... 24
Table 7: Example of Data Join Result inserted into tblFWPJoinedData ............................................ 25
Table 8: Example of Data Join Result with Missing Values ............................................................... 25
vi
List of Abbreviations and Acronyms

Abbreviation/Acronym Definition or Comment
DAL Data Access Layer
DMS file Deterioration Model Setup file
TSA Treatment Selection Algorithm
LRPs Long Running Processes (LRPs)
FWP Forward Works Programme or Forward Works Plan
FWD Falling Weight Deflectometer
vii
JunoViewer Web Framework Technical Guideline Introduction
1. Introduction
1.1. What is in this Guideline?
This guideline is aimed at JunoViewer Web users who are involved with setting up and administrating an
implementation of JunoViewer Web. The contents are fairly technical and we assume that the reader is
already familiar with the basic concepts of Road Asset Management and data processing in general.
If you are a regular user of JunoViewer Web and you are mainly interested in viewing reports and using
outputs, then this guideline is not for you! In this case you will be better off attending one of our in-house
training workshops or getting in touch with us directly to help you get started in using JunoViewer Web.
In the fast-paced modern internet era, major shifts in technology happen almost every three years. As a
result, any competitive software product has to keep on evolving to embrace and make maximal use of
emerging technologies. Web-based software in particular, is likely to evolve and change rapidly over time.
Also, today the pace of life, lack of time and nature of technology means that written user-guidelines that
tell users “how to do things” have become almost obsolete.
In our experience over many years, very few users have the time to print and read a document that is
more than 10 pages long. Also, because our software is likely to keep on changing over time, keeping a
written “how to” guideline up to date is a tremendous strain on our resources for very little benefit.
Because of this, what you will not find in this guideline are many step by step descriptions of
“how to do things”, i.e. which menus to click and so forth. Instead, what you will find is a
technical guideline that tells you “what things mean in JunoViewer Web, and how things work”.
For example, a Data Join operation is somewhat complex, and therefore we explain the Data Join
concept through innovative and easy-to-follow text and figures. Where needed, we also explain the key
input screens that you will need to complete before doing a data join. However, we do not give you a
step-by-step, screen-by-screen description of how to do a data join. If you are really interested in doing a
Data Join through JunoViewer Web, you will easily find this using our simple menu system and on-screen
help images. And if you get stuck for more than 5 minutes, you can just send us an email at
info@junoviewer.com and we will respond within 2 business days or sooner if possible.
Furthermore, the fact that the implementation of JunoViewer Web may look different for each client (see
Section 1.2 below), necessarily means that this guideline will not focus so much on reports and views
(which will be somewhat different for each client). Rather, the focus is on general technical principles that
apply to the framework in general. Owing to its complexity, the lion’s share of this guideline is devoted to
the Deterioration or Forecast model.
1.2. What is JunoViewer Web?

If you are not already familiar with JunoViewer Web, it is important to bear in mind that JunoViewer Web
is not a fixed, one-size-fits all application. Instead, our application can best be defined as follows:
JunoViewer Web is a framework for building web-based asset management systems
What does this mean? It means that JunoViewer Web provides the basic building blocks that can be used
to build a web-based asset management system to suit each client and environment. This is important to
understand, because it means that JunoViewer Web will not look the same for each client.
The basic elements provided by our framework include the following:
· A meta-structure for databases to hold information related to linear asset management systems.
1
· A Data Access Layer (DAL) that is optimized for performing queries on a database that hold
linear, time-based data such as those commonly recorded on road, rail and pipe networks.
· A world-class reporting system that is optimized for displaying linear, time-series data in
innovative and informative ways.
· Tools to store your current Forward Works Programmes (FWPs) in one central location from
where users can view, analyze, modify and export FWP information.
· Tools to perform sophisticated analysis on your data, such as batch-driven calculation of
deterioration rates and batch-driven analysis of the impacts of interventions.
Although the basic menu system and home page layout is the same for most clients, each client has the
opportunity – by working with Juno Services – to use these framework elements to build an application
that suits their needs perfectly. Thus clients with a good understanding of their network as well as their
specific analysis and reporting needs will get much more “bang-for-buck” out of using the JunoViewer
framework.
1.3. How to use this Guideline

The recommended way to read this guideline is as follows:
1. Start by doing a thorough study of the Key Definitions in Section 0. Test yourself at the end to make
sure you are familiar with key terminologies.
2. Do a quick study of Section 4 to refresh yourself on our menu system so you understand how things
fit together in the bigger scheme of things.
3. Do a quick read-through of the Table of Contents, and then of the rest of the guideline. This read-
through should give you a good idea of what is discussed and what you can find in this guideline.
4. If you are technically minded and would like to have a thorough understanding of each aspect of
JunoViewer Web, take each section at a time and study it thoroughly. Contact Juno Services to help
if you need clarification.
5. If you are more pressed for time, then, in the spirit of “necessity is the mother of invention” we
recommend that you tackle each individual section only when you really need to use it.
1.4. Our Sidebars

Throughout the guideline you will find yellow and blue sidebars like those shown above. These sidebars
highlight aspects that are particularly important, or which are vital to implementing the concepts. The
meaning of the two types of sidebars is explained below.
Sidebars with a little “time-bomb” next to them denote things that may bite you if you do
not do them right. For example, in these sidebars we will point out things that you have
to do right, otherwise errors may occur.
Sidebars with an “info-book” next to them denote things you need to take note of in
order to implement the concepts in practice. For example, in these sidebars will point
out when you need to ask Juno Services to do something on the back-end on your
behalf, or when you need to set up a specific file in order for things to work.
2
1.5. Stay Updated!

The contents of this guideline are likely to be modified quite frequently, especially in the early years while
JunoViewer Web goes through its teenage growing pains. Whenever you need to study a specific section
in depth, please check whether there is a newer version online (the version of your current document can
be found on the front page). Note that Appendices are held in separate documents so also check that
appendices are up to date. To get the most recent version of our guideline, log on to JunoViewer Web,
then go to the Settings Menu and select Help and Guidelines.
Some background and technical information is held in separate files as Appendices.

Before you use information in any of the appendices, please check to ensure that the
appendix file you are using is the most recent one!
Help Use Improve this Guideline
The JunoViewer Web framework is currently growing at a rapid pace. Because of this,
most of our resources are focused on the development and testing of the application,
and not so much on expanding the guideline. If you run into problems or uncertainty
about concepts while using JunoViewer Web, and you find those concepts are not
included in this guideline, please get in touch with use at info@junoviewer.com and let
us know where you would like us to expand this guideline. With your feedback we can
optimize our resources and ensure this guideline is of maximal use to you.
3
JunoViewer Web Framework Technical Guideline Key Definitions
2. Key Definitions
The following paragraphs provide some key definitions which need to be understood by users of the
system. While some of these definitions may seem obvious, it is important to understand their meaning in
the context of the software application, and therefore detailed explanations of all key concepts are
provided. Figure 1 illustrates some of the concepts explained in the paragraphs that follow.
Figure 1: Illustration of some key concepts
2.1. Network
A network is defined as logical group of network sections. Any logical group of sections can be defined as
a network. For example, a network can consist of all roads within a suburb, a province or a specific
freeway. In JunoViewer Web, networks cannot share the same Forward Works Programme (FWP) and
therefore networks typically have different treatment options, budgets, etc.
2.2. Section
As shown in Figure 1, a section is defined as part of a network with a specific ID and a unique set of
linear locations in each lane. In road networks, sections typically contain several lanes. All data measured
and stored on that section needs to be referenced by the section ID. The ID of each section should be
unique across all networks. Thus, you cannot have a section with ID = 13 in network 1 and also in
network 2.
JunoViewer Web does not automatically assign IDs to network sections. When you import your network
section definitions, you need to provide an ID for each section, and this ID has to be unique over all
sections, regardless of which network the sections belong to. The ability to use user-defined IDs for road
sections makes it easy to incorporate section definitions and data that was previously held in another
Asset Management System or database.
2.3. Segment
A segment is defined as part of a section – typically defined for analysis or modelling purposes. As shown
in Figure 1, a segment could be the leftmost lane of a specific section, thereby forming part of a section.
In some cases, a segment will comprise the entire section.
2.4. Treatment Length

Within JunoViewer Web, a treatment length is the same as a segment as defined above and in Figure 1.
The main difference between a segment and a treatment length lies in the use context. When a segment
is discussed or analysed in the context of a FWP or in terms of a treatment planned for that segment, we
4
will often refer to the segment as a Treatment Length. Thus, generally speaking, segments which are
defined within a FWP with assigned treatments, will be referred to as treatment lengths.
2.5. Modelling Segment

A modelling segment is the same as a segment as defined above and in Figure 1. As with a treatment
length, the main difference between a segment and a modelling segment lies in the use context. When a
segment is discussed or analysed in the context of a deterioration or forecast model, then the segment is
generally referred to as a modelling segment.
2.6. Segment Group

As shown in Figure 1, a segment group is defined as a grouping of segments to form a reporting or
analysis unit on the network. For example, you can define a Segment Group which comprises all
segments that received a rehabilitation in year 2013, and then label that group of segments as “Treated
Segments 2013”. In network view, you can then conveniently obtain statistics or reports using data that
fall within those segments.
2.7. Lane Segments

A “lane segment” is defined as a segment of a road that is specific to a single lane. In Figure 1, segments
1 and 3 are lane segments, while segment 2 is not a lane segment. Lane segments are optional
information about a network, and are often used for:
· Modelling purposes, where treatments may vary depending on the lane code;
· Plotting purposes (e.g. to show where a climbing lane starts and ends).
Lane codes can be uploaded directly via JunoViewer Web’s user interface, but can also be created from
lane configuration codes using JunoViewer Web’s FWP pre-processing tools. Refer to Section 0 for more
information on this topic.
2.8. Forward Works Programme

A FWP is a programme of works that is defined over a set of segments. In JunoViewer Web, a FWP
consists of a table where each row is a different segment. A FWP must belong to a network, and each
network can have more than one FWP. These different FWP’s linked to a network can represent different
versions of the same FWP, or it could represent work plans associated with different maintenance
aspects (e.g. one dealing with road works and another dealing with vegetation control). Each version of a
FWP is regarded as a separate plan. There is no formal or model linkage between two versions of the
same FWP. Figure 2 illustrates this concept.
We recommend you download a FWP template and inspect this to better understand the structure of a
FWP in JunoViewer Web.
Figure 2: Relationship between FWPs and Networks
5
2.9. Segment Set

A segment set is similar to a FWP, but does not have to contain any treatments. Thus you can define a
Segment Set to logically group any set of segments on your network. Like FWP’s, segment sets allow you
to quickly select a segment on the network and view the data trends within that segment.
2.10. Data Join Parameter

A Data Join parameter is a definition for a database column that can be included in a data join (see
Section 9.2 for more information on Data Joins). You can think of a Data Join Parameter as a shortcut
that tells JunoViewer where to obtain data that should be used in a join operation, and also how that data
should be processed to obtain a single join result value.
2.11. Table Link

The term “Table Link” is used in the JunoViewer Web framework to denote the underlying information
(meta-data) related to a specific table in your database. Table Link information is not stored inside your
database, but is held in a separate administration database. The information held for each Table Link
includes aspects such as:
· Name and label of the table.

· Whether the table holds date specific (time-series) data, and if so, the name of the column that
holds the survey dates.
· Whether the table holds point or segment data, and the names of the columns that hold the
location start and (if applicable) location end information for each data row.
· Whether the table holds lane specific information (i.e. each row/observations pertains to a specific
lane), and if so, the name of the column that contains lane codes.
In addition to the above, Table Link information also holds information on all columns in the table,
specifically the name, label and data type for each column in the table. Since column names are often
somewhat cryptic (e.g. “surfDate”), column labels are more user-friendly and are used in reports and
graphs. Column labels and data types need to be defined in the Table Definition Template when you add
a table through the menu system.
To add a table link when adding a new table, go to the Data menu, then select Add Table. To modify
Table Links for existing tables, go to the Data menu, then select Manage Table Links.
2.12. Long Running Processes (LRPs)

A Long Running Process, or LRP, is a process that runs on the server and may take a long time to
complete (several minutes to several hours). LRPs are initiated when a Deterioration Model is run, or
when a data intensive Tool is being executed (e.g. Data Joins). LRPs are run on a separate thread on the
server to ensure that the process is completed, and the results stored successfully, whether or not the
user is still connected. See the blue sidebar in Section 3.4 for more information about LRPs.
2.13. Point Data

Point Data refers to data that has a specific single location on the network. An example of a Point Data
type is a Falling Weight Deflectometer (FWD) reading. Each FWD measurement is taken at a specific
point, and therefore FWD data is held in a Point Data table. When you create data tables in JunoViewer
Web, you need to specify whether the table holds point or segment data. This is done as part of the Table
Definition process.
2.14. Segment Data

Segment Data refers to data that covers a specified length and location of the network. An example of
Segment Data is maintenance work performed over a length of road, or rut depth measurements
6
aggregated over a 10 m segment. When you create data tables in JunoViewer Web, you need to specify
whether the table holds point or segment data. This is done as part of the Table Definition process.
7
JunoViewer Web Framework Technical Guideline Overview of the Menu System
3. Overview of the Menu System

JunoViewer Web uses a simplified menu system that is very easy to understand. In this section, we give
you a brief outline of the main menu items and what you can expect to find under each item. As noted
earlier, JunoViewer Web is likely to change over time, so the menu layout may well change from time to
time. However, you should find that the main menu items remain intact. If you understand what types of
tools and reports to expect under each of the main menu items, then – with a little thinking on your part -
you should be able to find your way around our menu system quite easily.
A typical home page layout is shown in Figure 3. This figure also highlights the main menu items and
provides a brief description of what you will find under each menu. More details on each of the main
menu items is provided in the sub-sections that follow.
Figure 3: Outline of a typical Home Page with Main Menu
It is important to keep in mind that JunoViewer Web is a framework for building web-
based asset management systems. Because of this, the menu item for each client may
look somewhat different. The outline of the menu items given below is therefore
generalized and may not look exactly the same as what you find in your implementation
of the JunoViewer framework.
8
3.1. Views menu

The tools and reports you will find under the Views menu all relate to viewing and understanding your
available data. Users that are not administrators are likely to spend most of their time using the tools
found under this menu.
Aspects included under the Views menu are summarized in Table 1.
Table 1: Sub-menu items found under the Views menu

Views Menu Sub-Item Description
Section Compare This view allows you to compare the condition and performance of different
Sections within a specific network. If you want to compare sections across
networks, use defined Segment Groups in the Group Compare view (next
item). Figure 5 below shows an example of a Section Compare view that
implements a dashboard-type display that can compare the condition of
hundreds of sections at one time. Talk to Juno Services to customize the
dashboard display to show columns that suit your needs
Group Compare This view allows you to compare the condition and performance of different
Segment Groups. Since segment groups can be defined across different
networks in your database, you can use this view to compare the condition
of groupings of segments over different networks if needed. See Section
2.6 for the definition of Segment Groups.
Network Compare This view allows you to compare the condition and performance of different
Networks in your database. At present (Oct-2014) JunoViewer Web does
not allow comparisons to be made across different databases.
Forecast View The Forecast View is the flagship of JunoViewer Web. This view provides
an informative view on the Forward Works Programme (FWP) and on the
likely future network condition, given the current set of planned works.
Forecast View is so central to the JunoViewer Web framework that we have
devoted an entire Section to it. See Section 4 for an in-depth discussion of
the Forecast View.
Stripmap View The Stripmap View is a generic implementation of a stripmap with feedback
boxes. Figure 6 below shows a typical example of a Stripmap View with two
feedback panels. Talk to Juno Services to customize the Stripmap View to
show strips and feedback elements that suit your needs.
Map View The Map View is a customizable implementation of JunoViewer’s generic
mapping view. Figure 7 shows an example of a Map View implementation.
As with other views, the Map View can be customized to show the layers
and feedback information you need.
SQL View SQL View (see Figure 8) allows you to extract data from a specific table
using a Structured Query Language (SQL) statement. This view is useful
for more advanced users who are familiar with SQL, and who want to
extract data to an Excel file for more in-depth analysis.
Custom Views In addition to the above views, which are standard for most
implementations of the JunoViewer Web framework, most clients also work
with Juno Services to develop “Custom Views”, i.e. views that are
customized to provide a specific perspective on the available data, or to
drive specific types of decisions. “Safety View” is a common type of custom
view, which shows information that can help to make more informed
decisions related to network safety improvements. Talk to Juno Services to
develop custom views to suit your needs.
9
Figure 4: Example of a view to Compare Sections
Figure 5: Example of a Dashboard view to Compare Sections
10
Figure 6: Example of a Stripmap Implementation
Figure 7: Example of a Map View Implementation
11
Figure 8: SQL View that allows a custom select query to extract data
3.2. Data menu

The Data menu holds functionalities related to database setup and data manipulation (i.e. import, export
and deletion of data). Aspects included under the Data menu are summarized in Table 2. It should be
noted that only users with Administrator and Data Manager permission levels can access items under the
Data menu.
The management of data within your database can be divided into two main task types:
· Management of tables and table structures;

· Management of data within each table;
As shown in Table 2 the JunoViewer Web framework provides menu functionalities that
assist with the most common and straight-forward data management tasks. You will
often find that the menu functionalities shown in Table 2 do not allow you to perform
more complex tasks such as migrating data from an entire database, modifying column
data types, deleting columns etc. For these types of data operations, you will have to
ask Juno Services to assist on the back end. In exceptional cases, and with
experienced administrators, we can also arrange a special login that allows you to
access your database directly by means of Microsoft’s SQL Server Management Studio
application.
12
Table 2: Sub-menu items found under the Data menu

Data Menu Sub-Item Description
Add Data This menu item allows you to append or replace data in or to a specific
table. You can add data from an Excel file or from a delimited text file, with
or without column mapping information. The data that you want to add
should be already uploaded into your Uploads folder (see item
Upload/Download Data further down in this table). If you want to import
data from another SQL Server database, or from files larger than 10Mb in
size, speak to Juno Services to perform the data import from the back end
for you.
Delete Data This function allows you to delete data from a specific table using the
information provided when the data was added, such as user name, add
tag and date added. This function will NOT work if your data was added on
the back end and the log information was not included. To perform a
custom delete on your data, speak to Juno Services.
Add Table This menu item allows you to add a new table to your database, and also
adds the Table Link information that holds meta data about the new table
(see Section 2.11 for details on Table Links).
Manage Table Links This function allows you to manage the meta-data related to an existing
table. This is often needed when tables are created or modified on the
back-end, as opposed to using the Add Table function described above
(see Section 2.11 for details on Table Links).
These sub-menu items allow you to manage the definition of Networks,
Networks,
Sections, Segment Groups, Lane Segments and FWPs and Segment Sets.
Sections Please see Section 2 for the definitions of each of these items. The
Segment Groups, definitions of these items do not affect your condition or information data
tables, but it determines how you view and select data on your database.
Lane Segments, For example, the list of Sections is used when you need to select a network
FWPs and Segment Sets section to view. Proper understanding and management of these items is
vital to the proper management of your JunoViewer Web account.
Upload/Download Data The Upload/Download Data page is used to upload or download data to or
from a specific folder reserved on the JunoViewer Web server for your
account. Figure 9 shows the layout of the Upload/Download Data page.
Access to the User
Templates The Templates page shows a list of available templates that you may need
to import data for specific functions. For example, on this page you will find
the template needed to define the structure of a new data table, as well as
the templates for defining Networks, Sections, Segment Groups etc.
Download Offline DB This function allows you to download an offline SQLite database that can
be linked to one of our customized field inspection viewers. A generic page
is available to allow you to select the tables and roads for which to
download data, but a more common approach is for clients to work with
Juno Services to develop a custom download function that downloads the
specific data you need in one single step, in a format that is used for your
customized field inspection tool. Talk to Juno Services to develop a custom
offline field inspection tool that can seamlessly integrate field inspection
data with your online JunoViewer Web database.
13
Figure 9: Layout of the Upload/Download Data page
3.3. Settings Menu

The Settings menu holds miscellaneous features that are needed to make JunoViewer Web work, or that
allow you to customize how JunoViewer Web works. Table 3 below shows some examples of features
you will find under the Settings Menu.
Table 3: Sub-menu items found under the Settings menu

Settings Menu Sub-Item Description
Manage Users This function allows administrators to add and delete system users. From
the Manage Users page administrators can also change the permission
levels for users, as well as which networks each user has access to. See
text below this table for more information on managing users.
Home Page Settings This menu item allows administrators to manage the banner image and
slogan that is shown on your JunoViewer Web Home Page.
Forecast Models This function allows administrators to manage Forecast Models. Effectively,
this comprises the definition of a Forecast Model setup by linking a specific
Deterioration Model Setup (DMS) file to a specific Forward Works
Programme. From this page, defined model setups can be checked for
errors and a model run can be initiated. See Section 4 for more details on
managing Forecast Models and Section 6 for more information on the DMS
file.
To add and remove users from the JunoViewer Web account, go to the Settings menu and click on
Manage Users. Note that only users with Administrator permissions are allowed to add, edit or remove
users. Each user added to a JunoViewer Web account has a permission level. There are currently three
permission levels: Administrator, Data Manager and Regular.
14
Administrators automatically have access to all networks in the database, whereas Data Managers and
Regulars can have reduced permissions so that they can see only certain networks when using
JunoViewer Web. It is strongly recommended that most users be assigned regular user permissions.
Data Managers should be power users that have undergone extensive training in the use of the system,
and Administrators should be the elite of the power user group.
The different user permission levels are summarized in Table 4 below. Note that for certain customized
implementations of JunoViewer Web, these permissions can be modified as needed by the specific client
requirements.
Table 4: User Permissions for different levels

Function Administrator Data Manager Regular
Add and remove Users Yes No No
Add and remove Data Tables Yes No No
Upload and download Data Files Yes Yes No
Add and remove Data Yes Yes No
Run and administer Forecast Models Yes Yes No
View and export Reports or Data Yes Yes Yes
View and export FWP Yes Yes Yes
Use analysis Tools Yes Yes Mostly
Approve modified FWP data Yes Yes No
3.4. Tools Menu

The Tools menu holds functionalities that allow you to perform batch calculations and sophisticated
analyses of your data. For example, JunoViewer’s tool set includes a feature that facilitates the
calculation of Deterioration Rates which are often used to calibrate Deterioration Models. Table 5
contains a list of the current set of tools in JunoViewer Web with a brief outline of each tool. More in-depth
information can be found in Section 1. The list of available tools will grow over time, so please check for
updated versions of this guideline from time to time.
Table 5: Sub-menu items found under the Tools menu

Tools Menu Sub-Item Description
Create Segment Set This function allows you divide each Section of a selected network into a
set of shorter segments of specified length. The resulting set is combined
into a single table that contains all the segments for the selected network.
The output of this tool is exported to an Excel file which is automatically
downloaded when the algorithm is finished executing. See Section 9.1 for
more information.
Create Data Join Set This function allows you to combine data from different tables into a single
joined result. The join tool includes powerful features to automatically
aggregate join data by calculating selected statistics as the join is being
performed. See Section 2.10 and 9.2 for more information.
Deterioration Rates This tool allows you to calculate deterioration rates on a set of segments
that are imported from an Excel template that has been uploaded into your
Uploads Folder. See Section 9.3 for more information on how deterioration
rates are calculated and what can be done with the output.
My Running Processes This function allows you to see which of your Long Running Processes
(LRPs) are in progress and which have been completed. From this page,
you can also download the results of LRPs. See the blue sidebar in this
section for more information about LRPs.
15
Managing your Long Running Processes (LRPs)
Some of the functionalities that are available under the Tools menu may take a long
time to complete (from several minutes to several hours, depending on the size of the
data set that is being processed). Data Join operations, in particular, can take several
hours to complete when they are performed on large networks.
Such long running processes are problematic from a web application viewpoint,
because the user may be disconnected or logged out before the process is completed.
For this reason, the JunoViewer Web framework has special means for handling LRPs.
Whenever a user initiates a process that may take a long time to complete, that process
is put into a queue which is checked every two minutes. Any process in the queue is
then started on a separate thread on the server, which means the process will complete
and store the results whether or not the user is connected.
For each user, a log is kept of any LRPs which are in process or completed. This log
can be viewed on the My Running Processes page, which shows any processes which
were completed during the last three days. If there is a result set associated with an
LRP, then a link will be shown next to that process, and the result set can be
downloaded via that link. If an error occurred during execution of an LRP, then an
informative error message will be displayed where available.
16
4. Forecast View
The Forecast View is the flagship of the JunoViewer Web framework. This view allows you to see any
Forward Works Programme (FWP) associated with any of your networks in a grid that shows where and
when treatments are scheduled. In this sense, the Forecast View is somewhat like a shared spreadsheet,
with a few important distinctions. These are the features of the Forecast View that make it very different
from a shared spreadsheet:
· Forecast View does not only display treatments in the grid, but also displays the predicted future
condition for a model parameter superimposed over the treatment regime (See Figure 10).
· Using Forecast View, you can easily switch the condition parameter for which predicted condition is
being displayed. For example, you can easily change the display from showing future predicted rut
depth to showing future predicted roughness.
· When treatments are modified in Forecast View for one or more segments, the Deterioration Model
associated with the FWP is immediately re-executed for those segments. Thus the impact of
treatment changes on predicted network condition can be immediately re-assessed.
· Adding to the preceding point, with Forecast View, when treatments are altered there is no need for
the costly process of appointing an external consultant to re-run a stand-alone model to assess the
predicted condition when treatments are changed.
· When the instant auditing feature is turned on, all modifications to the FWP are tracked when users
modify or remove treatments. Users can optionally be prompted to prove a reason for making the
change to a treatment, and these changes can be viewed by all users later on.
· The feedback functions within Forecast View allows you to instantly see the historical and predicted
condition of any model parameter that is linked to historical data. This provides an instant
assessment of whether or not the model is realistic in its predictions when compared to historical
trends.
Figure 10: Outline of the Forecast View display
The following paragraphs point out the key aspects of the Forecast View and will help you get started in
using this view. As noted in the introduction, this guideline is not a “How To” manual, so please see the
online help images on the Forecast View for a more updated set of help images.
17
4.1. Using Forecast View

Figure 11 shows the key elements of the Forecast View toolbar. Note that these figures may be
somewhat outdated owing to the constant adding of new features to the Forecast View.
As indicated in Figure 11, when you open Forecast View, some of the menu items will
initially be hidden until you have selected the FWP you want to see. Once you have
selected the FWP and modelling parameter to view, the other toolbar buttons will be
visible.
Figure 11: Outline of the Forecast View toolbar
18
JunoViewer Web Framework Technical Guideline Deterioration Model Pre-Processing
5. Deterioration Model Pre-Processing

One of the core functionalities that JunoViewer Web provides is the set of tools that can assist with the
pre-processing that is required before a Forward Works Programme (FWP) can be created through either
deterioration modelling or field inspections or – more typically - a combination thereof.
In essence, this pre-processing process consists of the gathering and combining of available information
so that a set of model segments can be created (i.e. an empty FWP) and so that available information
can be collated and linked to each segment.
Figure 12 shows the steps that are typically performed as part of the pre-processing for creating a model
set. The following two aspects are important to note with regards to the model pre-processing process:
· Not all of the steps shown in Figure 12 need to be performed. In some cases only certain steps may
be required because other steps were already completed within an external third party system. Thus,
for your specific implementation of the JunoViewer Web framework, you may only enter the process
shown in Figure 12 at the fourth step, or you may need only the first two steps and the final step.
· FWP pre-processing is always applied at the network level. Thus, the output of each step is a list of
rows with a specific network ID.
Figure 12: Outline of Modelling Pre-Processing Steps
19
5.1. Creation of Lane Segments from Lane Configuration Data

The creation of lane segments (as defined in Section 2.7) relies on two sources of data which are
combined and then inserted into the Lane Segments table. The two sources of information are (a) the
table of defined Lane Configuration TYPES; and (b) the table containing the lane configuration type for
each part of each section of the network.
The relationship between these two tables is illustrated by example in Figure 13. In this figure, the lane
configuration table shows a situation where a specific road section has a two direction, two lane road from
km 0.0 to 2.0. The road then changes to a four lane, two directional road from km 2.0 to 2.9, after which is
changes back again to a two lane road.
Figure 13: Relationship between tables holding lane configurations and lane configuration types
It will be noted from the example shown above that a lane configuration type ID that appears in the last
column of the lane configurations table HAS to have a matching ID in the Lane Configuration Types table.
It is also critically important that the comma delimited lanes description in the last (“Lanes”) column of the
lane configuration types table must be correct, otherwise the wrong number of lane segments will be
created.
Figure 14 and Figure 15 show some of the lane configuration types which are commonly used to set up
the data in the Lane Configuration Types table.
The data in the Lane Configurations table should always cover the entire length of a
network. If not, the lane segments that will be created will not be fully representative of
the entire network and this may lead to errors. For example, in the case where lane
segments are used as the basis for deterioration modelling, an incorrect number of lane
segments may mean that the cost of required future treatments is under-estimated.
It is recommended that the total length of segments specified in the Lane Configurations
table always be added up to ensure that the defined lane configurations cover the entire
network. This should be done outside of JunoViewer before FWP pre-processing tasks
commence.
20
Figure 14: Examples of Lane Configuration Types – single carriageway roads
Figure 15: Examples of Lane Configuration Types – dual carriageway roads
Because lane configuration data seldom changes, JunoViewer Web currently does not
have a means for manipulating the data within the Lane Configuration Types and the
Lane Configurations tables via the User Interface. Maintenance of data within these
tables currently has to be executed by Juno Services staff via direct access to the SQL
Server database. Send your data to Juno Services in spreadsheet format and we will
check and upload the lane information data for you free of charge as part of our support
services.
21
As noted earlier, the creation of Lane Segments comprises the combining of the Lane Configuration
Types and Lane Configuration tables. The outcome of this combination (or join), is showed in Figure 16
below.
Figure 16: Schematic illustration of the Lane Segments creation process
As can be seen from Figure 16, the Lane Segments table contains the normal identification columns
(sectionID, lane, location from and to). In addition, the table also contains the following information:
Column Definition Example Data

width_lane Width of the lane segment, in metres 3.7
width_shoulder_L Width of the Left shoulder, in metres 2.5
width_shoulder_R Width of the Right shoulder, in metres 0
year_open Year in which the lane is open 2016
year_close Year in which the lane is closed 2099
The columns “year_open” and “year_close” are used by the Deterioration Model to determine whether or
not a specific lane segment forms part of the network for purposes of costing and condition assessment.
Through manipulating the dates in this column, the situation where lanes are added to, or removed from,
the network at a future date can be simulated.
Once the lane segments for a network are created, the lane and shoulder width information as well as the
years in which lanes are opened or closed should be completed. This process is discussed in the
following section.
22
5.2. Finalize Lane Segment Information

Once the lane segment information has been created, the Lane Segments table (“tblLanes”) will contain
one row for each lane segment within the network. When these rows are initially created using the
process described in Section 5.1, the columns containing the lane and shoulder width information as well
as the lane open and lane close data will be empty.
In order to use the lane segment information for modelling purposes, these empty data columns first need
to be completed. There are three basic approaches that can be followed:
· Export and External Manipulation:

In this approach, the generated Lane Segment data is exported using the JunoViewer Web interface
(go to the Data menu, then select Lane Segments). The exported data can then be manipulated
using Excel or any external data processing algorithm in order to complete the missing values for
lane widths, shoulder widths and open-and-close years. Once the external manipulation is
completed, the completed lane segment data can be re-imported via the JunoViewer Web user
interface.
· Bespoke Algorithm to Assign Lane and Shoulder Widths:
In this approach, the generated Lane Segment data is used in conjunction with an algorithm which is
customized to suit the needs of a specific client. For example, in situations where lane widths are not
known with certainty, widths can be assigned based on traffic volumes or location (e.g. urban or
rural).
· Combination of Bespoke Algorithm and External Manipulation:
This approach is a combination of the above two approaches. Typically, the bespoke algorithm is
first executed to complete some information, after which the lane segments are exported for further
external manipulation. The finalized lane segment set is then re-imported into JunoViewer Web via
the user interface.
Check the Customization Guideline for your company to find any specifics related to
the Lane Segment algorithm (if any) that is implemented in your JunoViewer Web
account.
5.3. Generate Lane-Specific Modelling Segments

Once the lane segment information has been created and completed, segments of the required length
can be created. This process uses the same algorithm as the Segment Set Creation tool (see Section
9.1). However, in this case the resulting set of segments is inserted into a special table
(“tblJoinSegments”) rather than being exported to an external Excel file, as is the case with the Segment
Set Creation tool.
The key input to this process is the length of segments that need to be created. Segment lengths of
100m are typical. The resulting set provides a basis on which a Data Join can be performed to combine
data from various tables for each created segment. This process is explained in the next section.
23
It is important to realize the difference between Lane Segments and Lane-Specific

Modelling Segments. In the present context, Lane Segments represent any lane
segment and as such can be of any length. Modelling Segments, however, are created
on the basis of Lane Segments, but are all of the same (specified ) length.
The table below shows the structure of tblJoinSegments with some example data:
Table 6: Example of Result Set in tblJoinSegments

ID SectionID LocFrom LocTo Lane
181150 1252 0 100 L1
181151 1252 0 100 L2
181152 1252 0 100 R1
181153 1252 0 100 R2
181154 1252 100 200 L1
181155 1252 100 200 L2
181156 1252 100 200 R1
181157 1252 100 200 R2
181158 1252 200 300 L1
181159 1252 200 300 L2
181160 1252 200 300 R1
181161 1252 etc etc etc
5.4. Perform Data Join on Created Segments

Once the modelling segment set has been created, JunoViewer Web can apply a Data Join on each
segment using the specified Join Parameters. See Section 9.2Error! Reference source not found. or
more details about Data Joins and Join Parameters. In the present context, where a data join is
performed as part of the FWP pre-processing process, we will refer to the data join as an “automated
data join”.
To utilize the automated data join in your model set creation, the following needs to be in place:
· A Data Join parameter needs to be created for each parameter you want to join into the result set.
To create Data Join parameters, go to Join Parameters under the Settings menu.
· Each created Join Parameter that you want to include in the automated data join should be marked
so that it can be identified as a “special” join parameter amongst the other join parameters that may
exist under your account. To do this, ask Juno Services to mark the join parameters you want to
include in the automated join, using the “isDefinedForModel” column/flag on table
“tblJoinParameters” in the JunoViewer Web administration database.
· For each join parameter that is marked with flag “isDefinedForModel” on table “tblJoinParameters”,
a matching column must exist on tblFWPJoinedData. In this case, the column name must match
the short code that is assigned to the join parameter.
The table below shows an extract of a data join process, the result of which are automatically inserted
into tblFWPJoinedData when the data join is executed as part of the FWP pre-processing process. In this
example, four join parameters were used in the automated join. These are:
·
th
85 percentile of FWD maximum deflection (D0) represented by the join parameter with code
“fwdD0_85th”;
24
· Maximum AADT represented by the join parameter with code “AADT_Max”;

· Maximum of ESA per day, represented by the join parameter with code “ESAday_Max”;
· 85th percentile of IRI (roughness) represented by the join parameter with code “IRI85th”;
As can be seen from the example below, in tblJoinedData, one column was created for each of these
data join parameters.
Table 7: Example of Data Join Result inserted into tblFWPJoinedData

ID networkID sectionID locFrom locTo lane fwdD0_85th AADT_Max ESAday_Max IRI85th
6904 888 1252 0 100 L1 1816 25157 1168.3 2.17
6905 888 1252 0 100 L2 1816 25157 1168.3 2.17
6906 888 1252 0 100 R1 1816 25157 1168.3 2.17
6907 888 1252 0 100 R2 1816 25157 1168.3 2.17
6908 888 1252 100 200 L1 646 25157 1168.3 2.323
6909 888 1252 100 200 L2 646 25157 1168.3 2.323
6910 888 1252 100 200 R1 646 25157 1168.3 2.323
6911 888 1252 100 200 R2 646 25157 1168.3 2.323
6912 888 1252 200 300 L1 651 25157 1168.3 2.4265
The Data Join process is the most time-consuming and error-prone element of the FWP
preparation process. In order to ensure that the process will complete without error, the
preparation of data join parameters to be used, as well as the creation of the necessary
columns on tblFWPJoinedData, needs to be executed with care and precision. Talk to
Juno Services about setting up a robust automated join procedure to match your
needs.
5.5. Fill In Missing Data on Modelling Segments

One of the key challenges in deterioration modelling is the handling of missing data on modelling
segments. This is often a problem on networks where condition is not often performed in certain lanes
(e.g. fast lanes on freeways), and yet the model needs to take these segments into account. Because of
the realities of network level data collection, the result of the automated data join (previous section), may
often look like that shown in the table below:
Table 8: Example of Data Join Result with Missing Values

ID networkID sectionID locFrom locTo lane fwdD0_85th AADT_Max ESAday_Max IRI85th
6904 888 1252 0 100 L1 1816 25157 1168.3 2.17
6905 888 1252 0 100 L2 No Data 25157 1168.3 No Data
6906 888 1252 0 100 R1 1816 25157 1168.3 2.17
6907 888 1252 0 100 R2 No Data 25157 1168.3 No Data
6908 888 1252 100 200 L1 646 25157 1168.3 2.323
6909 888 1252 100 200 L2 646 25157 1168.3 2.323
6910 888 1252 100 200 R1 646 25157 1168.3 2.323
6911 888 1252 100 200 R2 No Data 25157 1168.3 2.323
6912 888 1252 200 300 L1 651 25157 1168.3 2.4265
If this set of data is used as a basis for the deterioration model, errors may result if proper default values
are not assigned. Although JunoViewer Web’s deterioration model allows you to assign default values as
25
part of the model initialization process, the model set pre-processing algorithm contains a more flexible
and powerful approach to handling missing data values.
In this approach, missing values on a segment are handled in three stages, as shown by the figure below.
It should be noted that this process is applied on each Join Parameter data type, which is normally
represented by a specific source table and column.
Figure 17: Procedure for Handling Missing Values
As can be seen from the figure above, the completion of missing values proceeds in three steps. First, the
model checks whether there is any data available for the current segment’s lane and section. If so, then
this data is used to calculate a specified statistic (e.g. 80th percentile), and this value is then used as a
surrogate to replace the missing value.
If no data is found for the specified lane and section, the process falls down a level and checks if there is
any data available on the same section, without taking lanes into consideration. If some data is found,
then this data is used to calculate a specified percentile which is then used as a surrogate to replace the
missing value.
If no data is found for the current data type on the entire section, then the algorithm has no choice but to
apply a specified fixed default value.
As can be deduced from the process outlined above, the model preparation algorithm that fills in missing
values needs to be provided with three setup parameters. These are the two statistics to use for levels 1
and 2, and the fixed default value to use for level 3. In JunoViewer Web, the setup for filling in missing
values is specified as XML within each client’s account setup data.
The XML setup needs to be filled in using setting key “ModelJoinParamBlankValueSetups” in the Settings
Name Value Pairs for each client account where needed. Speak to Juno Services about managing this
XML setup for you in the JunoViewer Admin database.
The figure below shows an example of the XML setup data. In this example, the third XML element
specified that for levels 1 and 2, the Most Frequently Found value is to be used as a surrogate for missing
26
data on parameter “SurfType”. If no data is found on the section, then a fixed surfacing type value of
“S2BR” is to be used.
Figure 18: Example of XML Setup for Filling in Missing Values
The XML setup needs to be filled in using setting key

“ModelJoinParamBlankValueSetups” in the Settings Name Value Pairs for each client
account where needed. Speak to Juno Services about managing this XML setup for
you in the JunoViewer Admin database before you try to use the missing value
completion process.
27
JunoViewer Web Framework Technical Guideline Deterioration Model Concepts and Setup
6. Deterioration Modelling – Concepts and Setup

In JunoViewer Web, deterioration modelling is the process of predicting the future condition of the
network based on a set of assumptions and constraints. For example, a deterioration model may be able
to predict the distribution of rut depth on a network, given an assumed annual increase in rut depth (i.e.
an assumed rut deterioration rate). Within JunoViewer Web, the deterioration modelling process is also
referred to as Forecasting or Forecast Modelling.
JunoViewer Web’s deterioration model is powerful and highly flexible. The model definition is largely
specified in a Model Setup file, (called the Deterioration Model Setup file, or DMS file) which is in an Excel
Template format . Using Excel’s equation tools, a model can be easily configured by any user with good
Excel skills and a good understanding of what needs to be modelled and how the setup file works.
JunoViewer Web implements two deterioration modelling scenarios which are described in the following
two paragraphs.
6.1. Modelling WITHOUT Assignment of Treatments

In this scenario, JunoViewer does not do any automated or algorithmic assignment of treatments.
Instead, the model simply uses a set of imported treatments (assumed to be already contained in the
FWP) and then predicts what the future condition of the network would be under the given treatment
regime.
This regime is often used when an existing model other than JunoViewer is used to obtain a FWP. This
FWP can then be imported into JunoViewer and used in conjunction with JunoViewer’s powerful Forecast
View, which facilitates day-to-day operational management of the FWP in a way that most other
deterioration modelling software does not do. Please see the paper by Jooste and Jooste (Nov 2013) -
listed in Appendix A - for an in-depth discussion of strategic versus operational management of a FWP.
It should be noted that the modelling scenario without assignment of treatments can still be used to
assign routine maintenance if the model is correctly configure. For more details about modelling with
assignment of routine maintenance, see Section 8.
6.2. Modelling WITH Assignment of Treatments

In this scenario, JunoViewer uses an algorithm to assign treatments based on a Treatment Selection
Algorithm (TSA). Thus in this scenario the model does both treatment selection and prediction of future
condition. This modelling scenario is more complex and requires and experienced user to define the TSA.
Technical detail of modelling with assignment of treatments is discussed in Section 7.
In JunoViewer Web, the TSA algorithm is normally contained in a bespoke (custom) module that is
developed to suit a specific client or network’s needs. This bespoke module is programmed outside the
core JunoViewer libraries and can be modified based on the changing needs of a specific client. For more
details about the general approach implemented in JunoViewer’s bespoke TSA’s, please see Section 7.
The following sections provide a guideline to the use of JunoViewer Web’s Deterioration
Model Setup File (referred to as the DMS file). In general, the DMS file is configured to
cover both the modelling scenarios described above.
If you are using JunoViewer Web only for forecasting of future condition without any
treatment assignment, then many of the model setup parameters may not apply to you.
This will be pointed out specifically in the model setup file and/or in the sections that
follow.
28
6.3. Handling Variations within Modelling Segments

One of the key innovations introduced by JunoViewer Web is the use of a deterioration model that is
capable of handling the variation of condition WITHIN modelling segments. The importance of including
raw data variations within modelling segments is outlined in the sidebar below. The following paragraphs
provide more details of how the variation of data within modelling segments is achieved.
The Importance of Modelling Variations WITHIN Modelling Segments
An often ignored feature of prevailing deterioration modelling approaches is that most

modelling software simplifies the network condition by aggregating (i.e. grouping) data
over modelling segments. For example, in the case of rutting prediction a model may
divide the network into 500 short segments and then calculate the current average rut
depth on each segment. This provides a set of 500 averages which then serves as a
surrogate for the actual network condition (which is in reality represented by as many as
10,000 rut measurements if high speed condition survey data is used).
The future Network Performance Measures (NPMs) that need to be predicted by

deterioration models are typically specified in terms of statistics calculated on raw data
points (i.e. the 10,000 rut measurements noted above) and NOT on the aggregated
averages which the model predicts. Therefore, statistics calculated on a set of modelling
segments are not the same as actual network condition. Rather, deterioration model
outputs should be seen as surrogates which – in well calibrated model – perhaps
closely mimics network condition in terms of trends but not in terms of absolute values.
A study by Juno Services (see paper by Jooste and Jooste, Nov 2013, in Appendix A)
has shown that the use of aggregated statistics, as opposed to statistics on higher
frequency data, could lead to under-estimation of budget needs to keep the network in a
specified condition.
A key conclusion drawn from the above-noted study is that network level statistics
based on a set of treatment length data is not the same as the statistics of the true data
distribution. An analyst or roads agency representative looking at a graph showing the
change in predicted 85th percentile rut could be under the impression that they are
looking at an estimate of the 85th percentile of 20m rut depth as required by the NPMs.
However, this is simply not the case – they are in fact looking at the 85th percentile of
the average rut on all treatment lengths.
In the case of the average predicted rut depth, the model will give a reasonable
estimate of the true mean of the population. However, the use of averages to assess
network condition on their own are almost meaningless since they provide no indication
of either data spread or upper percentiles which are much more likely to determine and
direct maintenance costs and activities.
JunoViewer Web addresses this problem by allowing the deterioration model to

work either on aggregated values, or on raw data values which are stored with
each modelling segment and then individually deteriorated over time.
29
The difference between modelling with and without the simplifying use of aggregates is illustrated in
Figure 19. In this figure, the topmost figure shows a situation more closely aligned with reality, in which
the condition of each modelling segment is represented by a set of observed values (e.g. rut depth
measurements). As indicated by the red and blue dots, some of these values may be representative of a
poor condition while others may be representative of good condition.
The bottom illustration in Figure 19 shows the situation as modelled by most prevailing deterioration
modelling software. In this approach, each modelling segment is represented by a single value, which is
often the mean value. By using an aggregated value, all of the variation of rut depth within the modelling
segment is lost and is not accounted for in the model.
Figure 19: Modelling without and with data aggregation
The ability of JunoViewer’s deterioration model to run based on aggregated values or raw data values is a
powerful innovation that provides a model output that is more closely aligned with the real world. Thus in
JunoViewer’s model, there could – for a specific model parameter - be more than one data point within
each modelling segment.
Effectively, this means that JunoViewer can represent a model parameter not only as a single aggregated
value, but as a distribution of values, within each segment length. The use of a distribution of values, as
opposed to a simplified aggregated value (e.g. mean of all points within a segment), leads to a more
realistic prediction of variability – and hence risk – when modelled data is forecast into the future. This is
shown in concept in Figure 11.
Figure 20: Modelling without and with data aggregation
30
JunoViewer’s ability to model either aggregated data values or a distribution of values on each treatment
length does introduce some complexity that users need to be aware of. Please see the sidebar below
for more information on the aspects that users need to be aware of in this regard.
JunoViewer’s ability to model either aggregated data values or a distribution of values

on each treatment length does introduce some complexity that users need to be aware
of. A key concept that needs to be grasped is that, when segment specific outputs
are shown in graphs or tables, a statistic needs to be specified.
For example, when predicted rut depths are shown across treatment lengths in the
Forecast View, what is being shown in the Forecast View table is a chosen statistic
which is calculated over each treatment length using either the aggregated value or the
raw data values, depending on which of the two scenarios shown in Figure 20 are used
by the model.
6.4. Spreading Variations over a Modelling Segment

When modelling is performed using raw data values (e.g. without data aggregation as defined above),
various challenges arise. A key challenge is the handling of data parameters with different numbers of
observations within a segment. For example, within a modelling segment there could be 12 raw data
points for rutting, but only one for FWD maximum deflection.
In order to assess the condition of a specific part of a modelling segment, the condition of all parameters
at that location needs to be known. However, since the number of raw data points can vary within a
segment, the parameters first need to be “evened-out”. The manner in which JunoViewer does this is
illustrated schematically in Figure 21.
Figure 21: Evening-out of model parameter values with different numbers of observations
As can be seen from Figure 21, JunoViewer Web uses the data parameter with the most observations
(rut depth in this example) and then spreads the other parameters so that the number of values for each
parameter is the same. This “evening-out” process occurs only while the model is running. Stored values
are always “collapsed-back” to the original values (left hand part of Figure 21) before the data is stored in
the database.
31
This evening-out process allows JunoViewer to make decisions and apply equations at each data point
shown on the right side of Figure 21. For example, using the evened-out matrix of values shown on the
right side of Figure 21, JunoViewer Web’s deterioration model can – at each data point - evaluate
equations that rely on multiple parameters (e.g. on rut depth and FWD as shown in Figure 21). This
feature is also used to determine whether maintenance actions are triggered at each data point (see
Section 8 for details).
6.5. The Deterioration Model Setup File

As noted above, in JunoViewer Web, the deterioration model’s assumptions and constraints are specified
in an Excel file (called the Deterioration Model Setup file, or DMS file), which has to be formatted in a
specific way. By making use of an Excel file, JunoViewer can access Excel’s powerful equation definition
syntax. More importantly, the use of Excel to define the model setup means that there is no need to
implement a complex and cumbersome user interface to define the model, as is the case with many other
deterioration modelling software. This also means that any user with moderate Excel skills can
manipulate JunoViewer’s deterioration model.
However, the disadvantage of using Excel to define the model setup is that the user has to have a very
good understanding of the required file format and how the model is defined through the DMS file.
Although JunoViewer applies an extensive check to ensure that the model setup file is free of errors and
inconsistencies, this will only work to a certain extent. If an un-informed user tries to manipulate the DMS
file without a proper understanding of the file structure – errors WILL occur.
A detailed guideline to the format and structure of the DMS file is provided in Appendix B. However,
please take note that the preferred procedure for creating and implementing a DMS file is to work in
conjunction with Juno Services - or an approved agent appointed by Juno Services. During this
cooperation, we will check to ensure your file is correctly formatted and that your modelling preferences
are likely to be executed correctly. In fact, many clients rely on Juno Services to manage the DMS file on
their behalf based on their specific needs. In such cases users do not need to have an in-depth
understanding of how the DMS file works.
If you want to have a more direct control over your DMS setup file, you will have to arrange for a training
session geared specifically toward the DMS file. After you have attended such a workshop, you should be
able to manage and refine your DMS file through the use of Appendix B and with support from Juno
Services or one of its approved agents.
6.6. The Link between FWPs and Model Setups

The preceding sections outlined some of the basic elements of the JunoViewer Deterioration Model, and
earlier Section 2.8 provided a broad definition of a FWP within the JunoViewer Web framework. In this
section, we take a closer look at the FWP definition and explain the relationship between a FWP and a
deterioration model setup file. This relationship needs to be understood very well before you can attempt
to do deterioration modelling with JunoViewer Web.
For JunoViewer Web administrators, the following points need to be understood and memorized:
· A FWP must belong to a network, and each network can have more than one FWP.
· Different FWP’s linked to a network can represent different versions of the same FWP, or it could
represent work plans associated with different maintenance aspects (e.g. one dealing with road
works and another with vegetation control).
· Each version of a FWP is regarded as a separate plan. There is no formal or model linkage between
two versions of the same FWP.
· Each specific version of a FWP can have only one Deterioration Model Setup (DMS) file associated
with it.
32
· A single DMS file cannot be used across different FWPs. Even though the details inside two DMS
files can be the same, the name of each DMS file that is linked to a FWP has to be unique. This
constraint is to prevent a situation where someone modifies a setup file in conjunction with FWP “A”
(e.g. by changing treatment rates) which then have an unforeseen effect on all other FWP’s linked to
the same DMS file.
· Before you can use Forecast View, you need to create an association between the FWP you want to
see, and the model that is linked to that FWP. You do this via the Forecast Models item under the
Settings menu.
Figure 22 shows these principles in concept. In this figure, there are several versions of the road works
FWP on Network B, but all these road works FWPs are linked to the same DMS file.
Figure 22: Relationship between FWPs, Networks and Model Setup Files
Key Deterioration Model Concepts
· A FWP must belong to a network, and each network can have more than one
FWP.
· Different FWP’s linked to network can represent different versions of the same
FWP, or it could represent work plans associated with different maintenance
aspects (e.g. one dealing with road works and another with vegetation control).
· Each version of a FWP is regarded as a separate plan. There is no formal or
model linkage between two versions of the same FWP.
· Each specific version of a FWP can have only one Deterioration Model Setup
(DMS) file associated with it;
· A single DMS file cannot be used across different FWPs. Even though the
details inside two DMS files can be the same, the name of each DMS file that is
linked to a FWP has to be unique.
· Before you can use Forecast View, you need to create an association between
the FWP you want to see, and the model that is linked to that FWP. You do this
via the Forecast Models item under the Settings menu.
6.7. Managing Links between FWPs and Deterioration Models

It was noted in the preceding section that before you can use Forecast View, you need to create an
association between the FWP you want to see, and the model that is linked to that FWP. You do this via
the Forecast Models item under the Settings menu. Figure 23 to Figure 25 below shows the page that
facilitates management of the links between specific FWP’s and DMS setup files.
33
It should be clear that before you create a link between a FWP and a DMS file, you need to set up the
DMS file. This process is best done in conjunction with Juno Services until you are familiar with how the
model setup works.
Figure 23: Page to manage Model Setups
Figure 24: Input form to add a new Model Setup
34
Figure 25: Checking and Running a Model Setup
6.8. Running Deterioration Models

Once you have your deterioration model defined and linked to a FWP, you can run the model. To run a
deterioration model, go to the Manage Forecasting Model Setups page, which can be accessed via the
Settings menu (see Figure 25).
Running a deterioration model is typically an iterative process. Because of the complexity of most
deterioration models, repeated runs are often required before a model is calibrated and ready for
operational use. During these repeated initial runs, any bugs or problems in the model are corrected, and
the model deterioration rates and treatment triggers (if used) are calibrated to give results that correspond
with historical observations.
It is important during these repeated runs that you take care to ensure that the model setup is correct for
what you want to achieve. Key decisions that need to be made are (see Figure 26):
· Whether or not to run the model with or without assignment of treatments. If you are running a
model that has already been refined through field inspections and for which all treatments are
thus already determined, then you want to run the model WITHOUT assignment of treatments. If
you do not, the model will replace all field modifications and you could lose a lot of work!
· Whether or not to clear all treatments before the run starts. If you are calibrating the TSA through
repeated modelling runs, then you should clear the treatments that were perhaps assigned by the
model in an earlier run before the new run starts, otherwise the model may not trigger any new
treatments.
· Whether or not to apply committed treatments (See Section 6.9). If you have cleared any existing
treatments on the model at the start of the run, then you need to re-commit the treatments that
have already been committed, otherwise the model will bypass these committed treatments.
35
Figure 26: Modelling Process Outline
6.9. Assigning Committed Treatments

As the name suggests, committed treatments are those treatments which are already committed in the
FWP. These treatments are typically identified based on aspects such as:
· Network capacity requirements (e.g. to add an additional lane to a section because of the high
traffic volumes);
· Practical considerations (e.g. work is being done in a certain area, so we fix what we can on an
adjacent section).
· Political or economic considerations (e.g. a need arises to upgrade a section because of socio-
economic needs).
· Assessments done through other systems (e.g. modelling performed outside of JunoViewer
Web).
To assign committed treatments to an empty modelling set, you need to prepare a list of committed
treatments in an Excel template. The format of this template is explained in Figure 27 below.
36
Figure 27: Format of template for defining Committed Treatments
Note that Committed Treatments assigned using the above process are those which are
determined by processes outside of the normal deterioration modelling task. If you
already have your entire FWP as a result of another process, then you can simply
convert this FWP to JunoViewer Web’s FWP template and import the entire FWP
thought the Data menu. You can then run the Forecast Model without any assignment of
treatments.
An example of this situation is where deterioration modelling is done by a program such

as Deighton’s dTIMS® software, and where the outputs of this model is used in
JunoViewer Web without assigning any additional treatments. See Sections 6.1 and 6.2
for more information about modelling with and without assignment of treatments.
37
JunoViewer Web User Guideline Ver 1 June 2014 Deterioration Modelling with Treatment Assignment
7. Deterioration Modelling with Treatment Assignment

When an asset deterioration model is tasked to assign treatments based on modelled network condition
parameters, the model typically needs to address two key issues:
1. Where and when should treatments be applied?

and:
2. What treatment should be applied?
The manner in which JunoViewer’s deterioration model addresses each of these two questions is
explained in the Sections X and Y, respectively. However, before we look into these questions, the
concept of a Work Section needs to be explained.
7.1. Work Sections in JunoViewer Web

In JunoViewer Web, a Work Section is defined as a section of road that is regarded as a single unit in
terms of project planning and logistics. The work section concept is illustrated in Figure 28. This figure
shows that work sections can be of any length and can cover all lanes of both directions of a dual
carriageway, or a single direction, depending on the needs and approach of the network engineer.
Work sections are typically chosen to coincide with the original construction contract limits, where
different parts of the network were constructed at different times and under different contracts. However,
experience has shown that there is an optimal length of work section for each network which will lead to
the best utilization of available funds. Thus long construction sections are sometimes sub-divided to
improve budget utilization.
Km 0.0 2.0 4.0 6.0 8.0 10.0 12.0 14.0 16.0 18.0 20.0 22.0 24.0
Work Section A Work Section B Work Section C

(all lanes, both directions) (all lanes, one (all lanes, all
direction only) directions)
Figure 28: Illustration of the Work Section Concept
Work sections should not be confused with uniform segments (i.e. sections of a road where condition
and/or surface type and age are relatively uniform). As defined in JunoViewer, and illustrated in Figure
29, a work section will typically include several modelling segments. These can be fixed length segments
or they can be defined based on a uniform sub-sectioning method.
38
Km 0.0 2.0 4.0 6.0 8.0 10.0 12.0
Overlay None Rehab Rehab Seal

Seal None Seal Overlay None
Allocation of Treatments on Work Section A in a specific year

(showing treatments for one direction only)
Figure 29: Assignment of treatments within a Work Section
7.2. Modelling with-or-without Work Sections

For many road networks, the use of work sections allow the model to apply treatments in a manner that
more closely mimics the way that many road networks are being maintained. This applies specifically to
networks that include multi-lane dual carriageway roads. By grouping fast and slow lanes on a specific
road section together, the model ensures that all lanes of that section will be treated in a single project at
the same time. If the lane segments are not combined into work sections, then a deterioration model may,
for example, assign an overlay to the slow lane on one year, and then apply the same treatment in the
fast lane two years later. In practice, this will seldom be practical.
Note that the grouping of modelling segments into a work section does not mean the model will assign
the same treatment to each segment within a work section. Using rules and triggers, the model will treat
each segment based on its current or predicted condition, and assign a treatment based on the
Treatment Selection Algorithm (TSA).
Figure 29 shows the manner in which the model may typically assign treatments to a work section within
a specific modelling year. For clarity, this figure only shows the treatment on one of the two directions. As
noted earlier, the model will apply treatments to all segments within a work section at the same time.
However, as shown in Figure 29, the selected treatment may be a “None” (i.e. no treatment is applied),
depending on the predicted condition for a specific segment.
39
Why JunoViewer Web does not attempt Optimization of Benefit Cost Ratios
The use of an optimization function based on life cycle cost or benefit cost ratios is
often implemented in deterioration modelling software. Some of the most well-known
commercial software implements optimization based on the “efficiency frontier”
approach in which the treatment strategy with the highest incremental benefit-cost
ratio is chosen. Although this approach is often preferred by clients and consultants for
its apparent rigour and sophistication, it is in fact a highly theoretical approach which is
not well-supported by the practicalities of real world road asset management.
Consider the following simplified example, in which a deterioration model compares
three treatment strategies:
In this simplified example, a thin overlay (“Ovl40”) followed by a reconstruction

(“Recon”) is shown as the optimal treatment strategy. This treatment appears to be
marginally more optimal than strategy B, in which a reconstruction is built sooner,
followed by a thin overlay later on.
Theoretically, this seems like a sound approach. However, what this approach implies
is the following: “Treatment strategy A is optimal conditional on the assumption that a
reconstruction WILL be built in 2019”. Thus if the 40 mm overlay is built in 2014, and
then the planned reconstruction in 2019 is not built owing to budget or network
condition changes between 2014 and 2018, then it means a sub-optimum treatment
was implemented. In fact, unless the reconstruction is guaranteed to be built in 2019,
the 40mm overlay in 2014 may be a really bad choice!
Thus an approach that uses treatment strategy optimization requires very strict
adherence to the model outcome over the full length of the analysis period. Any
modification of an optimized strategy is likely to make the strategy sub-optimal.
Since road network management is by nature an “open system” in which budgets are
sure to change over the medium and long term – JunoViewer uses a more pragmatic
approach in which the best first treatment is always chosen based on engineering
principles and on the information that is available at that time. Future treatments are
similarly based on the predicted condition at that time.
Experience has shown that this pragmatic approach results in a highly realistic
and practical three year Forward Works Programme. Treatments applied after
three to five years are likely to be less realistic but still serve as good indications of the
levels of investment that will be needed in the future as well as the likely future
condition of the network.
40
7.3. Determining WHEN and WHERE to apply treatments

In the deterioration modelling process, the timing and location of treatments is determined according to
the process illustrated in Figure 30. This process is outlined in detail in the steps below. Explanatory
notes to the figure are provided below.
Figure 30: Outline of the algorithm to assign treatments
Notes to Figure 30:
1. The Deterioration Model Setup file (DMS file) is specified in an Excel template. Details on the
configuration of this file can be found in Appendix B. However, as noted earlier, the preferred
approach to managing the DMS file is to work in conjunction with Juno Services to set up the file, or
to attend a training session on the DMS file structure and details. In brief, the DMS file defines
modelling parameters and treatment types. The file also contains the equations that govern how fast
the network will deteriorate, as well as other configurable parameters, such as:
o Number of years over which to model, and budget for each year;
o Inflation and discount rates;
o List of Treatments with costs and equations that indicate if treatment is triggered or not;
o List of Routine Maintenance actions with their reset values;
o Catalogue of structural treatments;
2. The model will loop over all analysis years and for each year apply treatments where triggered and
deteriorate or improve the condition of all modelling segments accordingly. The number of years over
which the model runs is specified in the DMS file.
41
3. Work Sections are logistical groupings of modelling segments. The ranking or prioritization of Work
Sections for treatment can be based on a single condition indicator (such as IRI), or it could be a
compounded model parameter which can be a function of several other parameters. Thus the
ranking parameter can be configured to act as an index which indicates the need for either repair or
preventative maintenance.
4. To determine whether a Work Section can be treated in a specific year, the model scans all
segments within the work area and determines how many segments have triggered treatments. The
Work Section will only be considered for treatment if a certain percentage of the segments within it
have triggered treatments (this percentage is a configurable model parameter). For example, if
treatments are only triggered on 30% of a work section, that work section will be not be treated in the
current year, and the next work section will be considered. For more information on treatment
triggers, see the detailed section on the Treatment Selection Algorithm (TSA) in Section 7.4 below.
In addition to considering the percentage of triggered treatments, the algorithm also looks at the cost
of (possible) treatment versus the available budget, and whether the allowable number of annual
projects (specified in the DMS file) has been exceeded or not.
5. If no treatment is selected, then the algorithm checks whether any maintenance is triggered. In the
model setup, maintenance actions are regarded as a special set of Treatments, and can be triggered
using the same mechanism as for other Treatments, with the following exceptions:
o Unlike Treatments, maintenance actions cannot be sub-selected using a design catalogue (see
Section 7.4 on TSA for details);
o More than one maintenance action can be applied in a specific year on one segment (as
opposed to regular Treatments, of which only one can be selected).
6. If no treatment or maintenance is applied on a given segment, then each model parameter (e.g.
rutting, IRI, surface age) is incremented using the increment setup provided in the DMS file. If a
treatment or routine maintenance IS applied, then each model parameter is reset (improved) to a
specific value based on the resets specified for the chosen treatment or maintenance type (specified
in the DMS file).
The figure below shows how reset values for treatments are specified in the DMS file. In this
example, treatment “Recon1”, when applied, will reset the current IRI value on the segment to 2.5,
while treatment “Ovlay1” will reset the IRI to 3.5. These reset values can easily be modified in the
DMS file, and can also be Excel equations as opposed to fixed values.
Reset Value
7. Once the model has considered all Work Areas in a specific year, all relevant data for each segment
is logged in the database before the model moves on to the next year. This data includes aspects
such as treatment types and cost (if any) so that Life Cycle Cost can be calculated as part of the
model output report.
7.4. The Treatment Selection Algorithm (TSA)

As can be seen from Figure 30, a critical component of the modelling algorithm is the Treatment Selection
Algorithm, or TSA. This component determines WHAT treatment is applied within the larger process that
determines WHERE and WHEN treatments are applied. The following section outlines the key features of
JunoViewer Web’s TSA mechanism.
Broadly speaking, the TSA implemented in JunoViewer Web can be configured in two ways:
42
· Simplified TSA, in which no traffic modelling is performed. Treatments are selected mainly on the
basis of current condition.
· Complex TSA, in which traffic modelling is performed. In this case, treatments can optionally be
filtered based on current condition, and then the design is finalized to meet the design traffic
requirements.
The discussion that follows outlines the workings of the second option (complex TSA with traffic
modelling). A simplified version of the TSA can be configured through the appropriate selection of triggers
and setting certain options, such as the TRUE/FALSE flag that determines whether or not the model
should perform traffic modelling.
It should be kept in mind that the TSA is highly configurable, and thus the discussion is on general
features rather than specifics of implementation. For details on how to configure the TSA for your
network’s needs, please refer to the DSM file configuration in Appendix B.
The TSA executes in the manner shown in Figure 31. Detailed notes to this figure are provided below.
Figure 31: Details of the Treatment Selection Algorithm execution
Notes to Figure 31:
1. The treatment triggers can be based on any or all of the available model parameters, as well as
some parameters that are intrinsically calculated by the model. Typical treatment triggers could
include the following:
o Surface type and age;
o Current structural capacity and remaining life;
o Current predicted condition, including for example Rut, IRI and Crack Index;
o Number of years since last treatment (committed or other);
o Number of years to next committed treatment (if any).
2. The treatment trigger equation is specified in the DMS file, and is an Excel equation that returns a
true or false value. This trigger equation can be easily programmed by an analyst who understands
the format of the DMS file (see Appendix B, but special training is recommended). Figure 32 shows
an example of a treatment trigger in concept, as well as the Excel equation which implements it. As
shown in this figure, a trigger will return false if there is a planned treatment within the next few
43
years, or if the surfacing type is inappropriate (e.g. concrete segment but treatment applies only to
flexible pavements).
Figure 32: Example of a Treatment Trigger setup with implementation in the DMS file
3. In the DMS setup file, a flag called “Use Catalogue” determines whether or not a treatment needs to
be refined using a design catalogue. This flag should have a value of true or false. If the value is
false, then the treatment is applied “as is” without further consideration of other treatments. If the flag
is true, then a further selection process is performed using the Design Catalogue which is defined in
the DMS file.
4. The first step of the selection of a treatment from the Design Catalogue is for the model to calculate
the predicted future design traffic, in millions of equivalent standard axles (MESA), based on the ESA
per day and the growth rate assigned to the segment. This is normally done as part of the model pre-
processing as discussed in Section 5. The calculated MESA value is then used to select the first
treatment for which the calculated MESA falls within the range specified in the catalogue. An
example of a Design Catalogue specified in the DMS input file is shown below:
The design catalogue can have any number of rows, and any number of treatments. However, each
treatment has to be also defined in the list of treatments in the DMS file, in order for the model to
know which reset values to apply.
As shown by the figure above, the Design Catalogue template allows the algorithm to perform a
refined selection of a Treatment based on the calculated MESA, as well as an optional additional
“Selection Parameter”, which can be any of the modelled parameters (e.g. Rut Depth). If the
selection should rely ONLY on the calculated MESA, then any model parameter can be chosen as
the “Selection Parameter” and then given a very wide range in the catalogue template, to ensure that
the row is always selected.
44
7.5. Treatment Triggering Within a Segment

It was noted in Section 6.3 that one of the key innovations of JunoViewer Web’s deterioration model is
that it offers the capability to perform modelling using raw data values (as opposed to a simplified model
which uses aggregate values to represent each modelling segment).
For the case where modelling is performed using variations within modelling segments, it will normally be
the case that there will be multiple sets of conditions within a modelling segment. An example is shown in
Figure 33 below (see Section 6.4 for a more in-depth discussion). The question then arises – how does
JunoViewer decide whether or not a treatment is triggered on a segment as a whole?
The answer is that JunoViewer investigates each condition set (i.e. each data “row” in Figure 33) one by
one and – at each row – determines whether or not a treatment is triggered. If the majority of points
trigger a specific treatment, then that treatment is assumed to be effectively triggered for the model
segment as a whole.
Figure 33: Model data within a segment when modelling variations within segments
For the case where modelling is performed using variations within modelling segments,
it will normally be the case that there will be multiple sets of conditions within a
modelling segment. The question then arises – how does JunoViewer decide whether or
not a treatment is triggered on a segment as a whole? The answer is that JunoViewer
investigates each condition set (i.e. each data “row” in Figure 33) one by one and – at
each row – determines whether or not a treatment is triggered. If the majority of points
trigger a specific treatment, then that treatment is assumed to be effectively
triggered for the model segment as a whole.
7.6. Summary
The preceding discussion outlines the process implemented by JunoViewer Web’s deterioration model for
the case where the model is tasked to select where and when to apply treatments, as well as which
treatment to apply. The first two questions are resolved through a prioritization process which compares
the condition of each Work Section at the start of the modelling year. The prioritization process also
45
considers the practicality of treating each work section by considering aspects such as % of work section
that has triggered treatments, available remaining budget and number of projects already assigned in the
year. All these aspects can be configured through the deterioration model setup file, which is detailed in
Appendix B.
Once the model has determined that a specific work section should receive a treatment in the current
modelling year, the Treatment Selection Algorithm (TSA) is used to determine which of the defined
treatments should be applied. The TSA uses triggers to determine whether or not a treatment is a feasible
candidate to use in a specific year. Triggers can be based on many aspects such as current condition,
remaining structural life and time since last (committed) treatment.
In addition to the treatment trigger selection process, the TSA also allows the model to refine the
selection of structural treatments by performing a further selection based on the design traffic and
(optionally) one other parameter. This selection relies on a Design Catalogue which is defined as part of
the DMS file (see Appendix B) for details.
It was pointed out that JunoViewer Web’s treatment selection process makes use of the Work Section
concept which logically groups modelling segments on the network together, and then ensures that each
of these groups is treated as a unit within a single project. This approach mimics the rehabilitation design
protocol followed in many countries, and specifically on multi-lane freeways, where larger areas of a
network are treated in a single project, thereby providing benefits of scale to aspects such as
establishment on site, design resources and treatments across adjacent lanes.
It was also noted that JunoViewer Web does not implement the concept of treatment strategy
optimization based on a benefit cost ratio. We do so for a specific reason, which is that an approach that
uses treatment strategy optimization requires very strict adherence to the model outcome over the full
length of the analysis period. Any modification of an optimized strategy (e.g. by removing or changing an
early treatment) is likely to make the strategy sub-optimal.
Since road network management is by nature an “open system” in which budgets are sure to change over
the medium and long term – JunoViewer uses a more pragmatic approach in which the best first
treatment is always chosen based on engineering principles and on the information that is available at
that time. Future treatments are similarly based on the predicted condition at that time.
Experience has shown that this pragmatic approach results in a highly realistic and practical three year
Forward Works Programme. Treatments applied after three to five years are likely to be less realistic but
still serve as good indications of the levels of investment that will be needed in the future as well as the
likely future condition of the network.
46
JunoViewer Web User Guideline Ver 1 June 2014 Deterioration Modelling with Maintenance Assignment
8. Deterioration Modelling with Maintenance Assignment

JunoViewer Web’s deterioration model can be configured to assign routine maintenance as the model
executes. Details of the assigned routine maintenance can be viewed as part of the model output, which
includes graphs of the total predicted maintenance cost in each year, as well as cost breakdown by
maintenance type.
You can configure the model setup to apply routine maintenance irrespective of whether
you are performing modelling with or without assignment of treatments. So, for example,
if you performed a model run in an external software tool, you can import the treatments
as part of your FWP, and then run the model to predict future condition while assigning
maintenance actions where appropriate.
If you do NOT want JunoViewer to assign maintenance actions, then simple ensure that
there are no maintenance actions listed in the “Maintenance” sheet of the DMS file (or if
you have maintenance listed, ensure that the trigger flag always says “FALSE”).
8.1. Routine Maintenance versus Treatments

The manner in which Maintenance Actions (i.e. crack sealing, pothole filling, etc.) are defined in the
model setup is identical to the manner in which Treatments (i.e. overlay, seal, rehabilitation, etc.) are
specified in the DMS file. As such, maintenance actions are seen as special cases of treatments. It is
important, however, to note that - although maintenance actions are regarded as special cases of normal
treatments - the way in which the JunoViewer algorithm selects and applies maintenance is very different
from normal treatments as specified on the “Treatments” sheet in the DMS file.
The following are key concepts that need to be understood with respect to the way in which JunoViewer
assigns routine maintenance:
· In the case of Treatments (i.e. those actions specified on the “Treatments” sheet of the DMS file), only
one treatment action can be applied in a specific year to a specific segment.
· In the case of Maintenance (i.e. those actions specified on the “Maintenance” sheet), more than one
maintenance action can be applied to a segment in a specific year.
· Maintenance actions that are triggered are always inserted by the basic JunoViewer Web model,
irrespective of whether you perform modelling with or without assignment of treatments. If you are not
sure what is meant by “modelling with or without assignment of treatments”, please review Section 6.1
and 6.2 now!
· Treatment actions that are triggered are ONLY inserted for the JunoViewer Web models that have
been customized to do treatment selection. This means that – unless you are using a special
JunoViewer Web model that has been customized to select treatments - only treatments that have
been imported with your FWP will be considered, regardless of whether your treatment triggers
evaluate to TRUE or FALSE. Contact Juno Services if you need more information on this aspect.
· The manner in which variations within segments is handled is different for normal treatments and
maintenance. See Section 8.2 below for more details.
47
8.2. Applying Maintenance when Modelling Variations within Segments

As explained in Section 7.5, when modelling is performed with assignment of treatments, then treatments
are only triggered when the majority of data points within a model segment trigger that treatment. By
contrast, in the case of routine maintenance, each data point within a segment can individually trigger a
maintenance action, and the reset will be applied to each individual point within a segment.
This concept is illustrated in Figure 34. In this figure, we illustrate how maintenance can reset the severe
rut depths (red points in left part of Figure 34). Each of these individual points then have the reset value
that is determined by the triggered maintenance that has the most significant impact on rut depth.
Figure 34: Impact of Maintenance on values within a modelling segment
8.3. How Maintenance Cost is Determined

It is also important to note how maintenance cost is applied when modelling is performed with variations
within segments. For each of the data points as illustrated in Figure 34, JunoViewer web determines
whether or not a specific maintenance is triggered. The model then determines how many points within
the segment triggered that action, and calculates the cost as the number of triggered points multiplied by
the length associated with each point, where the length associated with each point is simply taken as the
length of the segment divided by the number of points.
Thus, if a segment is 220m long and there are 10 point sets within the segment (i.e. “rows” in Figure 34),
then each point is presumed to represent 22m of the segment. If two points (“rows”) trigger a
maintenance action, then the length of the effective maintenance is assumed by the model to be 22
multiplied by 2 = 44m.
The cost of the maintenance is then taken as the cost for maintaining the entire segment, multiplied by
the fraction that was effectively treated. In the case of the above example, the cost would be determined
by first calculating the cost of applying the maintenance action to the entire segment, and this would then
be multiplied by the fraction that was actually treated, i.e. 44 / 220m = 0.2 or 20% of the total cost would
be logged for that maintenance action.
8.4. Implementing Routine Maintenance in your Model

To implement maintenance actions in your deterioration model, you need to add the key routine
maintenance types to your DMS setup file (using the “Maintenance” sheet of the DMS file – see Appendix
B) for details. The figure below shows an example of a setup that specifies two maintenance types:
pothole filling (“potFill”) and crack sealing (“crackSeal”).
48
Trigger Flag
Reset Value
As shown in the figure above, the maintenance treatment setup includes an Excel formula that
determines whether or not a treatment is triggered. This equation is defined in the DMS file and can be a
function of the current model parameter values as well as parameters that are intrinsically calculated by
the model (e.g. number of years to next treatment). The maintenance setup also includes the reset values
or equations that determine the impact on the predicted condition of a segment when a maintenance
action is applied.
It was noted earlier that more than one maintenance action can be applied in a specific year. This
prompts, the question: how does JunoViewer reset a parameter value when more than one of the
maintenance actions influence that parameter? The answer is that JunoViewer considers the potential
impact of all triggered maintenance, and then applies the most influential reset value. Thus if one
triggered maintenance action resets the rut depth to 8mm and another resets the rut depth to 4 mm, then
the resulting rut depth on the model segment will be 4mm.
In the case of normal treatments (e.g. rehabilitation, overlay), only one treatment can be
applied to a segment in a specific year. However, in the case of routine maintenance,
more than one maintenance action can be applied in a specific year. This prompts, the
question: how does JunoViewer reset a parameter value when more than one of
maintenance action influence that parameter? The answer is that JunoViewer considers
the potential impact of all triggered maintenance, and then applies the most influential
reset value. Thus if one triggered maintenance action resets the rut depth to 8mm and
another resets the rut depth to 4 mm, then the resulting rut depth on the model segment
will be 4mm.
49
JunoViewer Web User Guideline Ver 1 June 2014 Tools in JunoViewer Web
9. Tools in JunoViewer Web

Within JunoViewer Web, there are several tools which are frequently used by network analysts to perform
tasks which would normally be time consuming if these had to be executed by means of spreadsheet or
hand calculations. All tools in JunoViewer Web can be found under the Tools menu.
Tools in JunoViewer Web are generally modular, meaning they can be executed separately and provide
outputs which are not automatically linked to tables in your network database. For this reason, the outputs
of Tool calculations are often provided in a spreadsheet for download. Once the tool output is
downloaded, it can be viewed and edited and then – if needed – imported into the relevant tables in
JunoViewer for viewing purposes.
9.1. Segment Set Creation

The segment set creator tool allows you to create a set of segments from a set of sections. Each segment
will have the same length, and this length needs to be specified when executing the segment set creation.
Figure 35 illustrates the use of the segment set creation tool.
Figure 35: Creating a Segment Set
If you tick the box “End Segments on Km”, the segment set will truncate uneven starting locations so that
subsequent segments end on the nearest round value. This is illustrated conceptually in Figure 36.
Figure 36: Impact of Segment truncation
50
If you tick the box “Split segments by Lane” your defined lane segments will be used to determine the
valid lane codes over each segment start and end location, and a separate segment will then be
generated for each lane. You can only use this function if your Lane Segments have been set up
beforehand.
9.2. Data Join

The Data Join tool allows you to join the information contained in many tables into a single table where
each row in the table relates to a specific segment. Figure 37 shows an example of a Data Join operation
in principle.
Figure 37: Illustration of a Data Join process
Before you start a join operation, you need to upload a FWP or Segment Set on which you want to
execute the Data Join. You also need to create the Join Parameters which specify which tables and
columns to include in the data join. To create a Join Parameter, go to the Settings Menu and select Join
Parameters.
A Data Join parameter is a definition for a column that can be included in a data join. You can think of a
Data Join Parameter as a shortcut that tells JunoViewer where to obtain data that should be used in a join
operation, and also how that data should be processed to obtain a single join result value.
The data join operations that JunoViewer Web can execute are extremely powerful, and allow several
options for processing of data during a data join. Figure 38 below shows the basic layout of the Join
Parameter definition page. This figure also illustrates the definition of a Join Parameter that will calculate
the percentage of Rut Depth observations that have a value greater than 10mm.
51
Figure 38: Defining Data Join Parameters
9.3. Deterioration Rate Calculation

The calculation of the rates of deterioration on parts of a network is an important element of deterioration
modelling – specifically for the calibration of deterioration models. JunoViewer Web uses a simple linear
regression to calculate Annual Deterioration rates (i.e. how much a parameter deteriorates in one year).
This ‘best fit’ approach yields significantly better results than simpler approaches (such as, for example,
taking the difference between values in successive years as an increment).
The reason why the ‘best fit’ approach works better is that it averages out random errors in
measurements for individual years. This concept is illustrated in Figure 39, which shows that the best fit
approach (regression line on right hand side) provides a different, and more appropriate, estimate
compared to a simple averaging of annual increments.
Figure 40 shows the form for setting up a batch calculation of deterioration rates, while Figure 41 shows
the format of the template that specifies which segments to perform calculations on. Note that the output
of a deterioration rate calculation is automatically downloaded as an Excel file such as that illustrated in
Figure Y.
52
Figure 39: Calculation of Deterioration Rates
Figure 40: Input form for calculating Deterioration Rates
53
Figure 41: Template for defining segments for Deterioration Rate calculation
An aspect of Deterioration Rate calculation that often causes confusion is that JunoViewer Web asks you
to specify which percentiles you want the deterioration rates calculated for. This is because the
calculation of deterioration rates will normally use a set of raw observations for each year, as shown by
the orange dots in Figure 42 below. In order for JunoViewer to calculate a best fit line on this data, these
raw data points need to be first collapsed to a single point for each survey/year.
The statistics or percentiles that you choose when performing deterioration rate calculations (see Figure
40 above) specify whether to calculate deterioration rates on a high percentile, a low percentile or
perhaps on a mean value. This concept is illustrated in Figure 42 below. JunoViewer Web allows you to
calculate deterioration rates on up to four statistics or percentiles at the same time. A deterioration rate
will be added to the result set for each chosen statistic.
Figure 42: Use of percentiles to calculate Deterioration Rates
54

JunoViewer Web User Guideline Ver 2

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

JunoViewer Web User Guideline Ver 2

Caricato da

Copyright:

Formati disponibili

JunoViewer Web Framework

Prepared For: Prepared By:

6.1. Modelling WITHOUT Assignment of Treatments ............................................................. 28

The following Appendices should be downloaded as separate files:

Appendix A: Useful References – Downloadable Zip File with .PDF Documents

Appendix B: Model Setup File Reference - Separate Document

Figure 2: Relationship between FWPs and Networks ......................................................................... 5

Figure 3: Outline of a typical Home Page with Main Menu .................................................................. 8

Figure 4: Example of a view to Compare Sections ........................................................................... 10

Figure 5: Example of a Dashboard view to Compare Sections ......................................................... 10

Figure 6: Example of a Stripmap Implementation ............................................................................. 11

Figure 7: Example of a Map View Implementation............................................................................ 11

Figure 9: Layout of the Upload/Download Data page ....................................................................... 14

Figure 10: Outline of the Forecast View display................................................................................ 17

Figure 11: Outline of the Forecast View toolbar ................................................................................ 18

Figure 12: Outline of Modelling Pre-Processing Steps ...................................................................... 19

Figure 17: Procedure for Handling Missing Values ........................................................................... 26

Figure 19: Modelling without and with data aggregation ................................................................... 30

Figure 20: Modelling without and with data aggregation ................................................................... 30

Figure 23: Page to manage Model Setups ....................................................................................... 34

Figure 24: Input form to add a new Model Setup .............................................................................. 34

Figure 25: Checking and Running a Model Setup ............................................................................ 35

Figure 26: Modelling Process Outline............................................................................................... 36

Figure 27: Format of template for defining Committed Treatments ................................................... 37

Figure 28: Illustration of the Work Section Concept .......................................................................... 38

Figure 29: Assignment of treatments within a Work Section ............................................................. 39

Figure 30: Outline of the algorithm to assign treatments ................................................................... 41

Figure 31: Details of the Treatment Selection Algorithm execution ................................................... 43

Figure 34: Impact of Maintenance on values within a modelling segment ......................................... 48

Figure 35: Creating a Segment Set .................................................................................................. 50

Figure 36: Impact of Segment truncation.......................................................................................... 50

Figure 37: Illustration of a Data Join process.................................................................................... 51

Figure 38: Defining Data Join Parameters........................................................................................ 52

Figure 39: Calculation of Deterioration Rates ................................................................................... 53

Figure 40: Input form for calculating Deterioration Rates .................................................................. 53

Figure 42: Use of percentiles to calculate Deterioration Rates .......................................................... 54

Table 2: Sub-menu items found under the Data menu...................................................................... 13

Table 3: Sub-menu items found under the Settings menu ................................................................ 14

Table 4: User Permissions for different levels .................................................................................. 15

Table 5: Sub-menu items found under the Tools menu .................................................................... 15

Table 6: Example of Result Set in tblJoinSegments ......................................................................... 24

Table 7: Example of Data Join Result inserted into tblFWPJoinedData ............................................ 25

Table 8: Example of Data Join Result with Missing Values ............................................................... 25

List of Abbreviations and Acronyms

1.2. What is JunoViewer Web?

JunoViewer Web is a framework for building web-based asset management systems

The basic elements provided by our framework include the following:

1.3. How to use this Guideline

1.4. Our Sidebars

1.5. Stay Updated!

Some background and technical information is held in separate files as Appendices.

Help Use Improve this Guideline

Figure 1: Illustration of some key concepts

2.4. Treatment Length

2.5. Modelling Segment

2.6. Segment Group

2.7. Lane Segments

2.8. Forward Works Programme

Figure 2: Relationship between FWPs and Networks

2.9. Segment Set

2.10. Data Join Parameter

2.11. Table Link

· Name and label of the table.

2.12. Long Running Processes (LRPs)