(from the February Editor's Note of AsphaltPro magazine)
I'm going to come right out and say it. AsphaltPro magazine's owner has no interest in the concrete industry. Therefore, when I hit the roof and started ranting about the American Concrete Pavement Association's (ACPA) manipulation of data to make asphalt pavements appear more expensive to produce than concrete pavements, Chris (the publisher) knew what was coming next. I complained (loudly) about what I considered unfair tactics while I pilfered the Internet and better primary sources to get the scoop, and then I prepared a scathing editorial for you readers. We're not offending any family members' advertisers by telling asphalt contractors the truth.
In a nutshell, ACPA developed a software program called StreetPave to assist contractors in determining lifecycle costs for both asphalt and concrete pavements based on what the software determines to be "equivalent" pavement parameters. The software, according to Asphalt Institute's Dwight Walker, uses AI's SW-1 software paradigm, but makes a modification to the data in the asphalt equation. "They made some sort of modification without explaining to the user what it was," Walker said.
My attempts to clarify that with other engineers went unanswered, but it looks like the StreetPave software literally reduces the subgrade strength of the asphalt design when the user punches in a number. This forces the program to add inches of asphalt subgrade to the asphalt pavement in the comparison. This means more material and more materials cost in the asphalt equation.
According to AI's Nov. 28, 2007, post on its Web site, "StreetPave takes the single subgrade strength value input by the user (only one value is allowed) and inappropriately reduces it prior to running the asphalt thickness design calculation." Because the concrete pavement design doesn't receive a similar reduction, the two pavements cannot be considered equivalent after all, and the asphalt pavement ends up being extraordinarily thick. In other words, the asphalt pavement turns out more expensive to build, in the StreetPave model, than it actually needs to be.
Now, how many people purchasing the ACPA product are making a roadbuilding decision between HMA and PCC? One would assume concrete producers purchase software to maximize their concrete-production efficiency from concrete industry members, just as asphalt producers purchase software to maximize their asphalt-production efficiency from asphalt industry members, so perhaps it doesn't matter that ACPA has something that appears blatantly underhanded in its marketing arsenal. Or perhaps it does.
Consider how precious the few projects being let in your county are. Do you want the local concrete producer to walk into the DOT office with a copy of StreetPave to show the materials engineer how much more expensive it makes the next pavement look over its lifetime if he elects to use HMA instead of PCC? You would be well served to let the engineer know that the subgrade number for the asphalt pavement becomes less than reliable in the StreetPave program.
It's a manipulation of data that needs to be fixed before the comparisons in the program can truly be considered "equivalent". After reading up on the product on the AI Web site, I wondered if anyone from AI had contacted ACPA to alert them to the problem (in case it was an honest error) and what the response had been. I didn't get answers to those questions, but they're good ones for asphalt industry members to follow up on. At the ACPA Web site, owners of the software can download a StreetPave v1.2 patch that mentions nothing about fixing a data-manipulation error. So it sounds to me as if the concrete industry still has a mistake to fix.
Stay Safe,
Sandy Lender
(Postscript: Since the publication of the February issue of AsphaltPro, I've learned that Asphalt Institute engineers have not received word from ACPA concerning their mistakes in software engineering, thus the apparent StreetPave error remains in place.)
Tags: AsphaltPro, Asphalt Pro, StreetPave
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment