A practical starting point for your digital twin
An EPC contractor manages engineering, procurement and construction for an industrial project. Its teams work across plant models, equipment documents and construction information. SDx helps organize engineering information; VBTech develops applications around the tasks those teams need to complete.
For example, a construction team may need to select equipment in a plant model and see its delivery status. A document team may need a usable translation of a Japanese technical PDF. We turn a defined requirement like these into an application workstream, with the relevant data sources and acceptance checks agreed with your team.
Who we build for
Our offer is designed for organizations using SDx to manage complex engineering and asset information, including EPC contractors, industrial owner-operators and their technology partners.
Based in Dubai, VBTech offers a software development workstream for EPCs and integration partners serving Gulf oil and gas projects. An EPC can bring us into the application layer while its platform and data teams retain responsibility for the underlying systems. The first discussion defines that division of work and the evidence needed for acceptance.
Different teams need different views of the same project. A useful extension should reflect their responsibilities and the decisions they make.
| Your team | A workflow we can help you scope |
|---|---|
| Engineering information management and document control | Bring document processing and multilingual access into the engineering information workflow. |
| Construction and project controls | Explore how progress, risks and delivery information could be presented against plant objects and project areas. |
| Asset owners and operations teams | Define the relationships between equipment, engineering documents and the information needed for handover or ongoing use. |
| IT, SDx administrators and integration partners | Specify application access, object mapping, data connections, hosting and acceptance requirements. |
You might already know the extension you need. You might also have a recurring operational problem without a technical specification. Both are useful starting points for a discussion.
Why extend SDx?
The starting point is often a task that crosses several interfaces: find a document, interpret its contents, locate the corresponding equipment and check information maintained by another team.
Consider whether any of these situations apply to your project:
- Documents cross language boundaries. An engineering team needs access to technical content in another language, while preserving a usable document and a clear review process.
- The model and the project report are separate. A user can inspect geometry but must switch tools to understand which objects a status or issue concerns.
- A dashboard lacks enough context. A summary reports a delay or exception, but users need to identify the affected assets and the source of the information.
- A digital twin initiative needs a first usable workflow. The team needs to establish what can be connected, who owns the data and how the application will be evaluated.
- An existing digital twin is difficult to use in everyday work. Project information is available, but users need a task-specific view to interpret it and act on it.
A custom extension can address a defined step in that workflow. The first objective is to make that step useful, testable and maintainable within your environment.
Our SDx integration services
Translation, plant visualization and dashboards illustrate our capabilities. We combine and extend these building blocks around your users, data and existing systems. They can form one application or support several connected workflows.
Technical document translation inside an engineering workflow
Our translation application processes technical PDFs between Japanese and English, Japanese and Arabic, and English and Arabic, in both directions.
Its processing chain combines OCR, translation and PDF reconstruction. The application includes a queue for tracking jobs and accessing source and translated documents. A contextual translation mode uses the document text to support consistency across the translation.
The implementation addresses document presentation as well as text conversion: translated text is positioned in the reconstructed PDF, with rendering designed to handle Japanese text and Arabic right-to-left layout. Quality and terminology requirements are evaluated against representative documents during project acceptance.
The application is designed to run within the SDx Web Client and also supports standalone operation. It includes document-reading integration components and uses staged processing checkpoints to support recovery after processing failures.
For each engagement, we define the document entry point, review responsibilities, terminology requirements and destination of the translated output. Document retrieval, processing and return-to-SDx requirements are specified together, including the permissions and document relationships involved. This turns a translation function into a workflow that users can evaluate from start to finish.
Plant visualization with object context
Our 3D application brings a plant model into a browser viewer built with three.js. The model preparation workflow starts with an export from Smart 3D through Smart Interop Publisher into IFC4, followed by conversion into GLB for browser visualization.
This separates the engineering exchange format from the format displayed in the browser. The IFC-to-GLB conversion step runs locally in the workflow we have built.
The application includes components for receiving selected SDx object identifiers, framing the corresponding model elements, retrieving object attributes through OData and opening SDx actions from a selection. These are the integration points to evaluate against the target SDx configuration.
This model workflow provides the technical basis for the visualization service. Responsibility for source-model export and conversion must be agreed separately; a conversion service is not automatically included with an application extension.
For users, the intended benefit is a model view that helps answer a specific question about an object or area. For implementation, the essential work is to preserve the relevant object relationships through conversion and verify how they connect to SDx information.
Project dashboards and a 4D timeline
We develop views for progress, risks, logistics and incidents, together with timelines for exploring changes by date. The application design brings related views into a shared interface, with each indicator tied to the information exposed by your project APIs.
A dashboard specification starts with questions such as which construction objects are affected by a delivery status, which information belongs in a risk view and what a user should see when selecting a date.
For 4D workflows, we define how schedule activities relate to model objects, how dates affect the display and how users navigate between an overview and a specific asset. Data ownership, mapping and update rules form part of the integration scope.
How this supports an industrial digital twin
The value of a digital twin workflow depends on the relationship between the asset representation, its associated information and the decision a user needs to make.
For our SDx offer, we focus on the application and integration work around that relationship:
- Represent the relevant assets. Prepare a model and identify the elements needed for the workflow.
- Connect the information. Establish how model elements, documents and source-system records refer to the same objects.
- Present the right context. Give each user a view suited to their task, such as document access, a selected plant area or project status.
- Define how information stays current. Agree the source of each value, its update rule and how stale or missing data should appear.
- Validate the decision path. Check that a user can understand the information, trace its origin and complete the intended task.
VBTech focuses on these application workflows and their integration with your exposed APIs. We define the relevant source, update behaviour and acceptance checks for each view so that users can interpret the information in its project context.
Hexagon SDx is now named Octave InConcert Core. We assess the product version and available interfaces for each integration.
The potential: connect a useful workflow, then extend it
An initial scope could focus on one document process, a representative plant area or a specific project-control view. This gives the team a bounded scenario in which to assess data quality, user interaction and integration behaviour.
If that scenario is accepted, subsequent work could extend coverage to additional model areas, data sources, user roles or workflow steps. Each extension needs its own data requirements and validation; a working viewer alone does not establish readiness for every digital twin use case.
For a programme with several dashboards, a shared application foundation can support successive use cases: common navigation, SDx interaction components and display conventions, with each new view evaluated against its own data and user requirements. Reuse would be assessed as part of the scope, including configuration and handover needs.
We establish measurable objectives with your team and use them to evaluate the delivered workflow:
| Potential objective | What to measure during evaluation |
|---|---|
| Make engineering information easier to reach | Time and steps needed to find the relevant document or object information. |
| Make a multilingual document workflow more usable | Time to obtain a reviewed output, with terminology and layout checks defined in advance. |
| Give project discussions better visual context | Whether users can locate the objects behind a status, risk or delivery exception. |
| Make data gaps visible before expanding the workflow | Coverage of object mappings, missing records and freshness of connected information. |
These measures help decide what to improve next and whether an extension is meeting its intended purpose.
How we deliver your SDx extension
1. Define the user problem and acceptance scenario
We work with the people using the application and those responsible for the platform. Together, we describe the task, its current steps, the expected output and the conditions that make the extension useful.
The output is a focused scope with user scenarios and acceptance criteria. This also identifies what belongs in the first implementation and what should remain a later phase.
2. Review the data and technical environment
We assess the SDx version, available interfaces, object identifiers, access permissions and representative documents or models. For dashboards, this includes the systems holding project information and how their records relate to the objects shown in SDx.
The output is an integration map covering sources, ownership, formats, read or write requirements and unresolved dependencies. Hosting and data-processing arrangements are agreed as part of this scope.
3. Build and evaluate a representative workflow
Development focuses on the agreed scenario before expanding its coverage. We organize the work around representative user tasks, interface requirements and agreed test data.
The evaluation covers both the normal path and relevant exceptions: missing object mappings, unavailable documents, processing failures or inconsistent source records.
4. Connect the agreed sources and run acceptance checks
The next stage verifies the application against the target environment and representative data. Relevant checks could include permissions, document processing, model conversion, object selection, dashboard values and update behaviour.
Acceptance is based on the agreed workflow and test evidence. Performance requirements are evaluated on representative hardware and data volumes.
5. Prepare deployment and handover
The final scope defines the deployment environment, configuration ownership, operating instructions and handover material. It also identifies responsibilities for updates, incident handling and future changes.
What the engagement can include
Depending on the agreed scope, deliverables can include:
- A workflow specification and data/interface map.
- A custom application designed for SDx Web Client Extensibility.
- Document-processing, model-preparation or dashboard components for the selected use case.
- Application-side consumption of agreed APIs, with object-mapping and display/update rules.
- Representative test scenarios and acceptance evidence.
- Deployment configuration, operating documentation and technical handover.
The scope should make clear what VBTech implements and what the platform or data owners provide. Typical inputs include environment access, permissions, representative data, source-system knowledge and business validation of the results.
The proposed visualization scope starts with information made available through agreed APIs. Source-system connectors, ETL and data provisioning remain with the teams operating those systems. SDx licences, infrastructure hosting and operation also remain with the client or its designated partners. VBTech's application work can include deployment packaging, installation and handover for the agreed environment.
Why discuss the project with VBTech?
Our work combines document-processing software with plant visualization and SDx application development. We bring concrete implementation experience in PDF rendering, SDx object context, IFC-to-GLB preparation and project-information interfaces.
Our offer is custom development around your workflow. We assess which components can be reused, which need adaptation and which require new development. The scope follows that assessment, with responsibilities and acceptance criteria established for your environment.
Speed, flexibility and room to grow
- Build from existing components. Our SDx interaction, document-processing and visualization components provide a starting point. We identify what can be reused and what needs adaptation when defining your delivery scope.
- Adapt to your users. A focused application lets us work on a specific task and review it with the people who use it. Their workflow guides the interface and the acceptance criteria.
- Extend a shared foundation. Common application components can support additional views, roles and workflows. We evaluate each extension against its data requirements, target environment and performance needs.
Questions teams ask before starting
Can you connect an existing planning or project-management system?
The project needs a defined path from planning records to the identifiers used by the application. Under the proposed visualization scope, your data team exposes the agreed planning information through an API; VBTech implements and validates its use in the application. The source-system interface and the application's use of that information have separate, clearly assigned responsibilities.
Can a digital twin dashboard show live project information?
We design dashboard integrations around the sources you expose, their update frequency and the mapping between source records and displayed objects. The scope defines refresh behaviour and how stale or unavailable information appears. This makes the meaning of “live” specific to your data and workflow.
Can you work with our existing IFC models?
Our implemented workflow prepares IFC4 models as GLB for the browser viewer. A representative sample would let us assess conversion, attributes, object relationships and visualization behaviour. Supported model coverage and performance would be established for the agreed environment.
Does local conversion mean the entire application runs on our infrastructure?
Local IFC-to-GLB conversion describes that specific preparation step. Hosting, document processing, storage and data transfers are separate design decisions. We establish those arrangements with your IT team when defining the architecture.
How would we evaluate translated technical documents?
We agree a representative document set, language directions, terminology requirements, layout checks and review responsibilities. Contextual translation uses the document text to support terminology consistency. Any dedicated glossary, approval process or additional quality workflow is specified as part of the engagement.
Can we start without sharing confidential models or documents?
Yes. The first discussion can use a generic description of the workflow and the systems involved. We can then agree what representative or anonymized material is needed for the technical assessment and how it will be handled.