DOC 02 OTL · Portugal · strategic · rev 2026.07
Over more than a decade, Belgium built the answer to a problem Portugal will face from 2027: how to digitally manage thousands of kilometres of network, thousands of civil works and hundreds of thousands of urban assets. The answer is called OTL. RFAS works at the Flemish road agency designing it — and proposes to Portugal a path to transpose it.
Table 02 · Indicators
Decree-Law 10/2024 makes BIM mandatory from 2030, with a pilot in 2027. The PortugalBIM Strategy was defined in the Council of Ministers (September 2025) and published in the official gazette in May 2026. CT 197 has worked on the normative framework since 2015. But this whole edifice is built on planning permission and buildings.
Infrastructure — roads, civil works, urban networks — falls outside the decree's direct reach. And that is precisely where the largest public CAPEX sits. Without a common data model, BIM in infrastructure is reduced to isolated IFC files with no real capacity for exchange, aggregation or inheritance into maintenance.
This is where OTL comes in.
Whoever reaches the table first with proven methodology sets the national standard. By 2031, this window will have closed or been filled by someone else.
An open, versioned, semantic conceptual model that defines how to describe each physical component of infrastructure — attributes, admissible values, typed relations. With unique, permanent identifiers.
ANALOGY
Think of an IKEA store. Every product has a code, a standardised data sheet (dimensions, weight, materials), and fits with other products in a defined way. OTL is the IKEA of infrastructure — a library where each object type (a luminaire, a sign, a drain, a pavement layer) has a defined sheet, and where what fits with what is formalised.
The difference: the catalogue is open, versioned, and any integrator can consume it via JSON-LD, validate against it in SHACL, and publish it back to the national portal.
The AWV-OTL took shape over the years as a broad semantic repository, covering the Standaardbestek SB250 / SB260 / SB270 trio. A Portuguese national OTL should be born multi-network and multi-domain — not confined to the perimeter of a single authority.
Pavement layers, joints, road markings, kerbs, stormwater drains, gullies, channels, retention basins, hydrocarbon separators.
Vertical, horizontal and luminous signage (full traffic lights), variable message signs (VMS), gantries, supports and foundations.
Bridges, viaducts, tunnels, retaining walls, culverts, technical stairs. Same semantic framework.
Cameras, traffic detectors, weather stations, radars, loop detectors, C-ITS roadside units.
Poles, luminaires, lamps, telemetry. Safety barriers, impact attenuators, noise barriers, fencing.
Trees, hedges, benches, litter bins, bus shelters, information totems. Plus accessories and auxiliary elements.
The OSLO/OTL methodology already extends beyond the AWV perimeter. Other bodies within the beleidsdomein Mobiliteit en Openbare Werken follow the same framework — De Vlaamse Waterweg (waterways), Departement MOW, Lantis (major infrastructure works). AWV today acts as the methodological facilitator of this expansion.
Versioned releases, active governance, continuous migration, managed compatibility. It works like Linux or buildingSMART's IFC — a technical community maintains, expands and versions it.
For Portugal, this means the discussion can never be "we define the OTL and it is done". The right question is another: who maintains the OTL over the next twenty years? What's the release cadence? What formal process receives contributions from the ecosystem? How is backward compatibility managed? These governance questions matter as much as the initial technical design.
Requirements gathering via ongoing projects, working sessions, gaps in DAVIE deliveries and tool users. Qualification and prioritisation by the OTL team. Modelling and peer review. Pipeline of environments with automated publication and regeneration of artefacts (HTML, UML, JSON-LD, SHACL, SQLite).
Each release is versioned (semver), with release notes and migration paths. Classes deprecated before removal. Downstream systems consume versions in a controlled way.
Scalable by size (municipal, IP, national). Designed, from the first phase, to sustain a living, versioned, multi-domain model.
Formation of the working group (IP, ANMP, CT 197, BUILT CoLAB, APA). Definition of the MVP scope. Governance study: model owner, release cadence, proposal process. Gap analysis against IFC 4.3, INSPIRE and OSLO.
Selection of 15–25 priority object types (proposal: urban vertical signage, high return, low complexity). Modelling in OWL/SHACL inspired by OSLO, with persistent URIs. Alignment with IFC 4.3 and INSPIRE. Publication as an open standard.
A mid-sized municipality (50–150k inhabitants) + a stretch of the national road network. Implementation across the survey → design → construction → maintenance chain. Delivery of SHACL-validated data. First post-pilot release. Metrics: inventory time, quality, rework avoided.
Roll-out to other volunteer municipalities (≈ 30 in a first batch). Extension to new domains — kunstwerken, drainage, urban networks — incrementally, release by release. Inclusion of OTL as a requirement in tender specifications.
OTL is not a software purchase. It's a common vocabulary that different players use for their own reasons — and that reduces friction between all of them.
Today they don't know how many traffic signs they have installed. In six months, with an OTL pilot, they do. Rigorous inventory, portals open to citizens, data-based planning.
The piece that links IFC 4.3 to asset management. A link between tender-specification items and the model's components. Automatic validation of deliverables. A versioned, migratable model that lasts 20 years.
Operational input from an OSLO domain in production. A national technical specification aligned with IFC 4.3 and INSPIRE vocabularies, referenceable in tender specifications.
Extension of DL 10/2024 to linear infrastructure without misalignment. A common vocabulary that resolves municipal heterogeneity without imposing a platform.
Eligible across multiple lines (digital transition, sustainable mobility, territorial cohesion), within the PRR and Portugal 2030 frameworks. Clear indicators. Low risk — Portugal doesn't fund research, it adopts a mature standard.
For the designer: less ambiguity, fewer revisions. For the contractor: the link between tender-specification items and the digital components reduces disputes at project handover.
A fundamental, low-visibility piece of the AWV-OTL: in Flanders, the postenmapping formally links each posten (an item of the standard specification, SB) to the OTL component(s) that work generates. Without this link, BIM would be disconnected from contractual reality.
With it, the measured works automatically generate the corresponding digital assets — closing the loop between budget, execution and asset base. It's one of AWV's differentiating contributions in the European landscape, and an area where RFAS has contributed directly.
In Portugal it would be one of the pieces that would make a difference: linking unit-price list items (IP, municipalities and others) to the components of a national OTL. What is bought is what is catalogued.
I currently work as an OTL consultant at the Agentschap Wegen en Verkeer (AWV), in Flanders. Daily, in production — modelling classes and running working sessions with experts.
RFAS Unipessoal Lda is the Portuguese vehicle for this practice. AWV is where I build, every day, the methodology that RFAS can bring to Portugal. No conflict: AWV operates exclusively in Flanders; the work in Portugal is outside that perimeter, under RFAS, with full transparency towards the Belgian structure.
The knowledge reaching Portugal is operational and current — not memory.
No commitment and no mandatory prior document. The aim is to answer a single question: does it make sense to move to a working session that defines the scope of a pilot? If yes, great. If not, the reason becomes clear — and that has value too.