Autodesk’s new AEC data model API marks the beginning of the transition from monolithic files, such as Revit RVT, to granular object data to open up new opportunities for sharing information and greater insight into projects. Martyn Day explores what this might mean for AEC firms moving forward
In AEC software, the last forty years have been about buying branded tools and creating associated proprietary files. Compatibility has been achieved by basically buying the same software as your supply chain and sharing the same proprietary files.
The next forty years will be all about the data: where it’s stored and how teams can access it. Monolithic desktop solutions will be replaced with discrete cloud-based services. These will provide different ‘snapshots’ of project data (different disciplines, project activities, meta data), which will be accessed through seamless Application Programming Interfaces (APIs).
The advantages will be no longer needing to send data around in big lumps, caching huge files, or cutting models up. Being centrally sourced, collaboration can be built-in from the ground level and granular data opens new data sharing opportunities, with greater insight into projects.
The key issue for the main software industry players, and their customers, is how do they get there? For companies like Autodesk, this is a significant challenge. It’s the market leader by volume, so has a lot to lose if it gets it wrong.
The company is currently developing Forma as its next generation cloud-based platform for AEC. Today, it may look like just another conceptual tool but there is a lot of engineering work taking place ‘under the hood’. In June, the day before AEC Magazine’s NXT BLD event, Autodesk announced the first downpayment on opening up the RVT file to new levels of granularity with the general availability of its AEC data model API. (cont…)
Find this article plus many more in the July / August 2024 Edition of AEC Magazine
👉 Subscribe FREE here 👈
The API is still in development and, for now, it only accesses metadata, without geometry, but this can be used to build dashboards or access design information that can be tabulated. Geometry will be the next layer of capability added to the API. At the time of release, Autodesk stated: “Through the AEC data model, we look to deliver a platform that prioritises a transparent and common language of describing AEC data, enabling real time access to this data and ensuring that the right data is available to the right people at the right time.”
![Autodesk API](https://aecmag.com/wp-content/uploads/2024/07/Screenshot-2024-07-22-at-14.41.44.jpg)
Over time, Autodesk will continue to build this capability out, allowing developers to read, write, and extend subsets of models through cloud-based workflows via a single interface. There will not be a need to write custom plug-ins for individual desktop authoring applications like Civil 3D, Revit, Plant3D and other AEC connected design applications. The filebased products will store their designs as files on Autodesk Docs and will be, on demand, ‘granularised’ to meet customers’ requirements. However, in order to make AEC data more accessible / interoperable everything must be restructured (converted) enabling the data to be remapped and connected across AEC disciplines. The company sees that the key delivery of the AEC data model API technology will lead to enhanced support for iterative and distributed workflows.
AEC data model API capabilities
As mentioned earlier, this is just an initial instalment of granular capability. The API allows the querying of key element properties from ‘published’ Revit 2024 and above version models – published meaning that the files are stored on Autodesk Docs.
The AEC data model API exposes these properties through a simple to use GraphQL interface, tailored to the AEC industry. GraphQL is an open-source data query and manipulation language for APIs and a query runtime engine.
Using GraphQL users can access Autodesk Construction Cloud (ACC) accounts, projects and designs and retrieve element and parameter values. It’s possible to retrieve different versions of a design and query for elements at a specific design version. Users can search for elements within a design or across designs within a project or hub using specified search criteria. It’s possible to list all property definitions and query elements based on their properties such as categories (doors, windows, pipes, etc.) or parameter name + Value (area, volume, etc.), materials.
Autodesk expects customers and developers to automate workflows, such as identifying anomalies within designs (quality checking) and locating missing information, comparing differences between designs. It’s possible to generate quantity take offs, schedules, build dashboards and generate reports.
For now, data granulation and viewing the results is free but there are rate limits, based on a point system. Overall, users are allowed 6,000 ‘points’ per minute. Each individual request is limited to 1,000 points per query. If you exceed these requests, Autodesk’s servers will not send you the information. The points system varies on the function – a query return is rated at 10 points, Object info in at 1. There is more information about his online.
Watch Autodesk’s NXT BLD 2024 presentation
For more information watch the NXT BLD 2024 presentation from Autodesk’s data experts, Virginia Senf and Sasha Crotty.
The talk includes details about the acquisition of Datum360, which aggregates and connects multiple data sources together and applies industry standards with compliance reporting.
Open or walled garden?
In recent times, Autodesk has been making a lot of noise about being open and being a better open citizen. It has licensed the Industry Foundation Classes (IFC) tool kit from the Open Design Alliance (ODA), the most used IFC creation tools, it has created export services on the cloud to translate between different applications, and signed multiple interoperability deals with competitors, such as PTC, Bentley Systems, Trimble and, most recently, Nemetschek.
But why are interoperability agreements required in the first place? If you are open, you are open and surely permission would not be required? A lot of these agreements are about swapping software, perhaps file format libraries but increasingly it’s about rights to have API access.
This is the big issue for cloud. If you move your data to the cloud, where it might be translated into a proprietary database format, the only ways to get access to your data are via file export or API calls.
The path to granularity
The AEC data model API enables the break-up of monolithic files, such as Revit RVTs and AutoCAD DWGs, into ‘granular object data’ that is managed at a sub-file level in Autodesk Docs on the company’s secured cloud. This data is accessible in real time via Autodesk’s APIs and enable new capabilities.
Today, while it would be great to get RVT, DGN, DWGs out with great file compatibility, in five to ten years’ time, this will be as exciting as getting a DXF. Project information for all disciplines at high levels of granularity will deliver greater collective benefits than relatively dumb files. API access really is at the control of each company and allows firms to wall off their customers’ data to selected developers.
Autodesk’s cloud-based API, which was called Forge but is now Autodesk Platform Services (APS) comes with terms of usage, once of which, 5.3 simply states, ‘No use by competitors – Except with Autodesk’s prior written consent, you may not access or use the services if you are a competitor of Autodesk.’
For me this seems to be the main reason for the agreements, to give express permission to access customers’ data via APS. But this isn’t given to all: it has to be negotiated and I assume it’s on a quid pro quo basis and probably on how much of a threat you are. This is a kind of openness, but it’s going to be highly conditional and could be revoked at any time.
If you move your data to the cloud, where it ‘‘ might be translated into a proprietary database format, the only ways to get access to your data are via file export or API calls
As all software moves to the cloud the API world is also trying to work out ways of financially rewarding the software firms. It is inevitable that API calls will be charged for. All this software is sat on Amazon AWS or Microsoft Azure instances and all traffic comes with associated micropayments. Software firms are examining models to cover these charges while adding their profit margin. In the case of Autodesk these are wrapped into the cloud credit system, covering functionality and the AWS bill. While the AEC data model API is currently free, it is throttled with an associated point system. Metering is an important metric for future business models.
Conclusion
Changing the fundamental technology on which your applications and customers have built businesses on is not for the faint hearted. Keeping desktop software sales alive, while re-engineering filebased workflows to ones that are granular is like changing a car tyre at 90 miles an hour. With the release of this AEC data model API, we now have some insight as to how Autodesk will engineer the data model component.
For now, you can use all Autodesk cloud services as you currently use them. Instead of forcing a translation between every Revit file save on the fly, the granularity of files is handled on demand, for those that want to take advantage of it. The API, now and seemingly for quite a while to come, is all about output from Autodesk Docs (viewing, tabulating, querying) as opposed to doing something to the data and sending it back to Autodesk’s servers. This, I guess, is mainly about security.
Being able to view granular info via a simple interface is obviously a huge advantage over file-based workflows, where a lot of the BIM metadata goes to die. In some respects, this is ‘an openness’ here, enabling the viewing of design data held in proprietary files, held in a proprietary database on a paid for service. The fact is you still need to be an ACC subscriber to generate the granular data in the first place.
The most interesting development will be when geometry can also be output with the meta data through the Autodesk AEC data model API. Will the geometry be Universal Scene Description (USD), or will it be like IFC.JS, with all the granular object data?
With IFC.js and open-source products like Speckle, it’s already possible to make data granular right out of the Revit desktop app, without having to pay to use Autodesk’s cloud services. The battle for granular data mobility has started.