One thing the AMDS needs to get right

The term AMDS refers to the Asset Management Data Standard. The AMDS project is developing a data standard for the New Zealand land transport sector.

Update: want to know more about the AMDS? Check out our independent resource for the AMDS over at amdshub.co.nz.

In today’s post we are covering two topics.

• First we look at some of the positive changes made in the recent April 2021 project update.

• We then discuss one thing that I think the AMDS needs to get right for a successful implementation. And a quick spoiler alert for you: its not related to any asset.

Let's jump in.

What is the AMDS?

I am going to go ahead and quote this straight from the AMDS website, as it provides a really nice description of what the project is all about...

"The Asset Management Data Standard (AMDS) is a collaboration between Waka Kotahi NZ Transport Agency, The Road Efficiency Group (REG) and the transport sector to improve the management of land transport infrastructure asset information that supports best decisions about New Zealand’s land transport assets.

AMDS will establish a common language the sector can share – a way of defining and describing land transport assets, their attributes, characteristics, properties, location and performance to enable efficient and effective end-to-end life cycle asset management."

So to put it another way; the project is going to create a way for everyone to speak the same language when we talk about land transport assets.

Good moves made in the April 2021 Update

The April 2021 update published by Waka Kotahi had some really good moves made by the project.  A few of the more significant ones include (in no particular order);

• AMDS outputs are now going to be distributed in more user-friendly formats!  The original ontological model visualiser will still be there, but it won’t be the only way to consume the standard. Whilst style-wise the model did have some some pretty slick animations, it was unfortunately a bit difficult to use.
  
  The screen was also prone to clutter, when viewing an object with lots of related items.  The screenshot below shows what happens when trying to view the attribution for surface assets for example.

Switching to file formats common to the industry will give a huge boost to user-friendliness and readability.  A really good outcome!

• Prototyping.  This is a biggie as well.  Marlborough Roads is being used as the first prototyping site, which is a mix of local authority and state highway roads. And the inclusion of sites in the prototype is likely going to expand over time.
  
  Building and testing the standard with real-world data, in a real-world environment, will be invaluable.  It will provide learnings, feedback and insights that simply wouldn't come if things were only done at a conceptual level.
  

• The implementation plan has been shortened from 10 years to approximately 5 years.  A screenshot of the revised implementation is below.

• There is a strong focus being channeled into change management, which again will be essential to a successful rollout.  There sounds like there will be a comprehensive approach in terms of looking at everything from documentation through to resourcing the implementation itself.  Really good stuff!

These are just some of the key changes released in the April 2021 update. If you want to find out more, you can watch the recent Waka Kotahi ‘AMDS drop in session’ below. This discusses all of these items in more detail.

One thing the AMDS needs to get right

I think there is one thing the AMDS absolutely needs to get it right.

It's not related to any asset in particular. It wasn't even in the original AMDS project scope (as far as I could tell). But it is important.

Like really really important.

I’m talking about networks. Or as I often refer to it; the network definition aspect of the standard.

What does network definition mean in this context?

Well in RAMM speak you can think along the lines of localities, road names, carriageways, intersections, centrelines and calibration points.

It's about all the things which are the building blocks to create a digital representation of a network. And it’s about how you use those building blocks in a consistent and structured way, to define each individual element of a network. And those elements could be part, or all of, a road or a footpath or a cycleway or whatever is relevant to the network.

The network definition is absolutely critical to the performance, management, analysis and reporting of land transport assets.  It essentially underpins everything that happens in this space, and is foundational to making the network and associated data hang together.

In the latest April 2021 update, a network definition item has now been added to the project. I think this is a fantastic move. The Network Group consists of things like Carriageway, Network Classification Zone, Road Centreline and Multi Modal Networks.

So it will be interesting to watch how this unfolds within the AMDS project. And it will be very interesting to see what level of detail is prescribed in the standard.

In my opinion, tackling this whole area of network definition as part of the AMDS will be no small undertaking.  It will take significant effort just to design, test and agree a ‘standard’ in principle. Let alone all the downstream processes, implementation needs, change management requirements, and data transformations that will inevitably need to follow.

What makes defining the network so challenging?

The overall subject matter of ‘network definition’ is rife with complexity. Loads and loads of complexity.  It needs to navigate things like;

• competing operational needs and requirements from different stakeholder groups 

• differing opinions and views on what capabilities the network definition should support and deliver

• multiple flavours of existing network definition standards (or a lack of standards as the case may be) 

• substantial differences in how legacy data has been configured and managed, both in terms of conventions and quality

• semantics; different terms can mean different things depending on the person or system. Reconciling between these can be challenging. For example, what is a carriageway to one person could be a route, or a link, or a segment, or a section or so on to someone else.

• the dependency of data and functional capabilities on the network

• data models and capabilities of existing systems in use today

• the shear diversity of real-world network configurations, which need to be classified somewhere and somehow within ‘the standard’

Let’s take a look at a very basic example to help illustrate this point about complexity. To do this we will use a short local road that is only 64m long.

Sorry, I meant the road is 130m long.

No wait, it is 64m long.

Or is it 130m?

Ok, I think we should just take a look.

How long is this road?

Your task is to define and configure this road in your asset management system.

It might be of interest to you that there is an island/median in the middle of the road. Then again that might factor into things at all.

So how would you define this road in your system?  What is your answer to the ‘how long is this road’ question?

Below are two common approaches to this kind of scenario.

Approach A: “Down the Middle”

Here you would create the centreline "down the middle" of the road. The centreline would run straight through the median area.

This would give you an approximate road length of 64m.

Approach B: “Around the median”

In this scenario you would create a centreline that follows the drive path around the median island. So unlike in Approach A, the start and end points of the road do not share the same vertex.

Using this approach would give you an approximate length of 130m.

Now for arguments sake, we will round this and just say that Approach B is double the length of Approach A (130m vs 64m … close enough!).

Wait….Double the length?

But this was just a short local road. And both options used seemingly logical approaches to defining the road. And yet the result is two wildly different road lengths?

Now just remember the network definition, which fundamentally includes the length of the road, underpins basically everything.

So the impact of not standardising these configuration approaches could have a material impact on downstream processes.

So what are some examples of these impacts?

Let’s consider a handful of hypothetical outcomes for our example road, comparing Approach A and Approach B;

• the AMDS specification for surface assets includes from and to linear attribution. In this scenario, the ‘to’ attribute of our top surface could be either 64 or 130m.  Yet both would be describing the location of exactly the same surface asset (quick note; this is ignoring the specifics of where the surface would start or end in relation to the intersection - buts that’s a discussion for another day)

• are you comparing surface asset lengths? the linear surface length from the other approach could be either 50% or 200% of the 'true length', depending on which method you think is the right one

• are you doing length based reseal achievement reporting? Those using Approach B could on paper be achieving twice the reseal length compared to those using Approach A. But again, it’s the same asset..

• do you have 'fault per centreline length' triggers in your decision analysis?  Perhaps this road triggers when it shouldn't, or maybe it doesn’t trigger when it should - simply due to how the road length has been defined.

Sure, some of these things may be validated and resolved in a downstream process. Some may have simple workarounds. Some may be inconsequential in the grand scheme of things.  

But the point is simply to show the importance of (and dependencies on) the network definition. And the need for this kind of thing to be standardised.

Without a comprehensive set of conventions and business rules in place, to help ensure networks are configured in a standard way, there will be data inconsistencies introduced, simply due to the network definition.

And when extrapolated out across a whole network (or the whole country!), these inconsistencies could quickly compound into something non-trivial. 

I think this really emphasises just how important the network definition subject area is. And I think it is inextricably linked to some of the key objectives of the AMDS project.

I will finish with this thought: to get everyone talking the same language about their assets, the AMDS needs to get everyone talking the same language about their networks first.

Want more information about the AMDS?

If you want to find all the latest information on the AMDS, head over to the AMDS page on the Waka Kotahi website; AMDS Project Page.