Introduction

Juno Cassandra, or Cassandra, is a software framework for Infrastructure Deterioration modelling (IDM). Cassandra combines the speed of the .NET framework and the C# computer language to create a framework in which you can develop, run and analyse IDMs of any complexity.

Cassandra is Lonrix’s fourth generation deterioration modelling framework. We believe it is the one that best strikes the sweet spot between out-of-the-box functionality and ease-of-customisation.

Juno Cassandra Architecture Objectives

In the design of the Cassandra framework architecture there were four key design objectives:

  1. Domain agnostic; meaning the models can be adapted to any type of Infrastructure (roads, water networks, bridges, powerlines etc.) without having to deal with or work around domain specific terms.
  2. Ease of sharing models and debugging;
  3. Optimised performance and structure to facilitate flexible ‘meta programming’ that will facilitate running models iteratively for purposes such as goal seeking, budget scenario analysis and model calibration; and
  4. Ability to incorporate Machine Learning (ML) predictive models.

The following paragraphs discuss each of these objectives.

Domain Agnostic

The current, DMS-based models that are popularly used in JunoViewer were originally designed with road networks in mind. Although the DMS models 1 have been used successfully to model Bridge Networks, and can be configured to model Water networks, the legacy of the original design means that the DMS based models contains some terminology that is specific to road networks. Examples of this include the mandatory model parameters for Length and Area.

With Cassandra, Lonrix is moving to a truly domain agnostic model. The model can be configured to model any type of infrastructure element such as bridge components, powerlines, water networks or road networks. In Cassandra there are almost no mandatory fields to include in a model, and where such fields exist they pertain to aspects such as ‘element ID’ and such which is completely divorced from any specific domain such as roads or bridges. This means that modellers should find it easy and intuitive to develop models for any domain without having to work around terminology that does not apply to the type of infrastructure they are working on 2.

Ease of Debugging

At Lonrix, our mission is simply: ‘To Help People’. When it comes to complex deterioration models, this can get tricky. When a client runs into a problem with a model they had defined, where does software support end and consulting begin?

When you get stuck with an IDM giving you results that are not as expected, where do you begin to find the problem? Normally, this will involve a trial-and-error process in which you change one thing after another until you can pin down where your problems begin and end.

At Lonrix, we go the extra mile to help clients debug their models. However, even we know that there is only so much you can do without taking full control of your client’s models - and that is impossible to do at scale.

We have struggled for many years with this problem - how to build a modelling framework where the client controls the details, but where our expertise can be utilised to help smooth their way through the complex process of debugging a deterioration model.

We believe with Cassandra we have made it possible for the client to have full control of the process. We have done our best to make debugging of a model simpler through ensuring that error messages are as informative as possible, and by issuing warning messages when we detect anomalies in the Domain Model configuration.

When all of the above fails to explain an anomaly or bug, it is possible for Lonrix to quickly run your model on an offline computer and debug into the problem. We have taken extra care to make this process as seamless as possible, thereby ensuring that we can provide problem-solving support when you need it.

Flexible meta programming

Cassandra was designed from the ground up to deliver the highest possible performance in terms of speed of execution. This performance objective was specifically aimed at our eventual goal of being able to use Cassandra as a way to perform fully fledged Monte-Carlo simulations that will allow decision makers to rationally assess the risks associated with the unavoidable uncertainties in key parameters such as treatment resets and deterioration rates.

Cassandra is therefore being designed to eventually facilitate a form of ‘meta-programming’ of the model so that experienced modellers can run their models in a loop. This creates the potential to use models in a goal-seeking algorithm to chase complex objectives. Cassandra thus becomes a tool that can be configured and used in different ways depending on the context and goals for the analysis.

Incorporating Machine Learning Models

The rapid growth in the use of Machine Learning (ML) models made it essential for us to ensure that Cassandra was ‘Machine Learning Enabled’. Traditionally, well known deterioration models such as the World Bank’s Highway Design and Maintenance Models (HDM models) (Paterson 1987) are used in IDMs. These models generally use equations that express regression or survival analysis models.

In Cassandra you can naturally implement such equation-based models. However, in addition to this Cassandra also makes it possible for you to replace or augment these traditional models with cutting-edge Machine Learning models.

Do you want to use a Support Vector Machine (SVM) model to predict rut increments on road networks? Cassandra can do that. If you want to use a Random Forest Decision Tree to express your treatment selection model - Cassandra can do that.

It should be noted that, for the ML component, Cassandra requires the ML.NET environment to be available for the .NET component of your framework. ML.NET is a powerful machine learning framework (provided by Microsoft) that can be easily integrated in compiled C# libraries.

For advanced modellers with intermediate C# programming skills, their pre-trained Machine Learning models can be loaded into the Domain Model at run time. After that, the normal predict() function can be used to extract the predictions from these models.

At this stage, the use of Machine Learning models in Cassandra is still somewhat complex and requires support from Lonrix Ltd. In the next year, Lonrix will work to make the inclusion of Machine Learning models more and more seamless.

Juno Asset Management System and Cassandra

Lonrix envisions that Juno Cassandra will eventually be fully integrated within the cloud-based Juno Asset Management System (JunoAMS) which means that Cassandra will be available as a browser-based application. For the immediate future, however, Cassandra will be available only as a desktop application.

The video below provides more information about JunoAMS and discusses how Cassandra fits into the wider Juno ecosystem:

References

Paterson, W. D. O. 1987. Road Deterioration and Maintenance Effects. Models for Planning and Management. London: Johns Hopkins University Press.

Footnotes

  1. DMS stands for ‘Deterioration Model Setup’. The DMS file is a setup file containing the expressions and parameters used in your model.↩︎

  2. Please note that the main author of these guidelines comes from a background in Road Engineering and because of this you may find that many examples used in this guideline pertains to road networks.↩︎