Platform
Alsadaany Industrial Twin
Alsadaany Industrial Twin holds a physical operation as a structured model of objects, relationships, states, events and constraints, runs that model forward under demand and disruption, and uses it to compare interventions before any of them reach the plant.
Definition
An operational model, not a scene
The value is the operational model and what can be computed over it. Three-dimensional visualisation is an interface onto that model. A system whose twin exists only as geometry can show you the plant; it cannot tell you what the plant will do.
- It is not a system of record. It reads from the systems that already hold your operational data and does not replace any of them.
- It is not a control system. Nothing in it is on the safety path, and safety functions belong on deterministic hardware rather than on anything learned.
- It is not a visualisation tool. Three-dimensional views are an interface onto the model, and a deployment can be useful without one.
- It is not a finished shrink-wrapped product. It is deployed through engineering, per operation, and the status of every layer is published above.
- It is not a monitoring or alerting product. It reasons about what an operation will do, which is a different job from watching what it is doing.
The operational model
Six primitives, and everything is one of them
The list is short on purpose. An ontology a domain expert cannot hold in their head is one they will not check, and a model no domain expert has checked is a model of an assumption.
- Objects
- The things the operation is made of. Each has an identity that persists, properties that describe it, and a state it is currently in.
- For example: Machines, cells, buffers, conveyors, vehicles, robots, operators, tools, materials, orders, containers, storage locations, stands, gates.
- Relationships
- How objects are connected, and therefore how a change in one reaches another. Topology is what turns a list of assets into a system.
- For example: Routes between stages, feeds, precedence, containment, assignment of an operator to a machine, network adjacency, physical proximity.
- States
- What an object is doing now, drawn from a defined set rather than inferred from a metric. States are what make blocking and starvation observable instead of estimated.
- For example: Idle, processing, blocked, starved, breakdown, maintenance, charging, in transit, queued, held.
- Events
- Discrete changes with a time attached. The simulation advances by processing them, and the operational history is a record of them.
- For example: Job release, stage completion, failure, repair, shift change, arrival, departure, replenishment, alarm, disruption.
- Constraints
- The rules the operation may not violate. A model without them produces answers the plant cannot execute, which is the most common way a simulation study is wasted.
- For example: Capacity, work-in-progress limits, shift patterns, skill requirements, safety interlocks, changeover rules, due dates, energy limits.
- Actions
- The interventions available. An action is a change that could actually be made, which is what separates a decision system from an analysis.
- For example: Add or reassign capacity, resize a buffer, change a sequence, reroute, reschedule maintenance, adjust staffing, change a dispatch policy.
How to read this page
Every capability carries its stage
Six words, used the same way across this whole site. They are published here so a label can be checked rather than taken on trust.
- Status: Production
- Deployed and running against a live operation, with the operator depending on its output.
- Status: Available
- Can be bought and delivered today under a written scope.
- Status: Pilot
- Delivered as a scoped first deployment, against a defined process and a defined dataset.
- Status: Demonstration
- Built, published and runnable so the engineering can be examined. Models an illustrative system, not a customer's.
- Status: Prototype
- Built and runnable. Demonstrates the mechanism; not yet packaged as a product.
- Status: Research
- Under active investigation. The approach is chosen; the result is not settled.
- Status: Planned
- A committed direction with a design behind it, and no implementation yet.
Nothing on this site is labelled Production. The word is reserved rather than retired: the definition above is what will decide when something may take it.
The structured description of the operation
Operational model
The plant, terminal, warehouse or estate written down as objects, relationships, states, events, constraints and actions. Everything above this layer computes over it, and no layer above it can be better than the model underneath.
Domain modelling of the operation
Status: AvailableBuilding the model of one specific operation, in the terms that operation actually uses. Delivered as engineering work, because a model built without the people who run the plant is a model of an assumption.
Objects, states and events as first-class structure
Status: PrototypeMachines with defined operating states, buffers with capacity, workers with assignment, and an event stream the model advances by. Demonstrated across four public systems in four different domains.
Model definitions held as data
Status: PrototypeA different facility is a different dataset rather than a different build. Demonstrated in the manufacturing and airport systems, where the plant and the terminal are generated from layout and equipment data at runtime.
Portable model interchange between deployments
Status: PlannedA documented schema for exporting and importing an operational model, so a model outlives the deployment it was first built in.
Running the model forward
Simulation
Discrete-event, agent-based and hybrid execution over the operational model, seeded and replicated so a result is a distribution rather than a single sample.
Discrete-event simulation
Status: AvailableQueueing, contention, blocking, starvation and failure as consequences of the model rather than as parameters of it. Delivered as engineering, and demonstrated publicly.
Agent-based simulation at operational scale
Status: PrototypePopulations with individual attributes and decisions, run in real time. The airport system is built to a target of 10,000 passengers, 100 aircraft and 500 ground vehicles.
Coupled physical models
Status: PrototypeSubsystems that share state, so a change in one propagates into the others through the physics rather than through a script. Demonstrated across orbit, power, thermal, attitude and communications in the mission twin.
Deterministic, seeded, replicated runs
Status: AvailableRuns are seeded and inputs versioned, so any reported figure can be regenerated exactly. Results are reported across replications with the deviation stated.
Headless execution engine with a job API
Status: PrototypeUrual, the company's simulation engine: a headless, plugin-first, job-based runtime in Go with an HTTP API, a job state machine, a worker runtime and an artifact store. In development and not yet ready for production use.
Comparing alternatives on measured evidence
Scenarios and analytics
A scenario is a defined change to the model. Comparing two scenarios means running both from an identical starting state and measuring the difference, rather than estimating it.
Scenario definition and comparison
Status: PrototypeThe manufacturing system answers a capacity or staffing question by instantiating two complete additional plants from an identical starting state, one as configured and one with the change, and comparing the outcomes.
Operational analytics and KPIs
Status: PrototypeThroughput, utilisation, lead time, queue depth and overall equipment effectiveness decomposed into availability, performance and quality, all measured from model state rather than displayed alongside it.
Constraint identification
Status: PrototypeThe binding constraint derived from stage capacity and corroborated independently by queue depth. Where the two disagree, the disagreement is itself the finding.
Disruption and fault injection
Status: PrototypeFaults and incidents injected into a running model, propagating through coupled subsystems by mechanism. Twelve incident types in the airport system, eight injectable faults in the mission twin.
Reporting and export
Status: AvailableResults delivered as data your own analysis can consume, with the assumptions that produced each figure attached to it. Scoped per deployment.
Searching the space of actions rather than checking a few of them
Optimization
Scenario comparison evaluates alternatives a person proposed. Optimization generates and searches them. The two are different problems, and the platform does not present the first as though it were the second.
Manual scenario search
Status: AvailableStructured comparison of candidate interventions defined by your engineers, evaluated by simulation. This is what a deployment does today, and for many decisions it is sufficient.
Parameter sweeps and design of experiments
Status: PlannedSystematic exploration across a defined parameter space, with the runs distributed over the execution engine.
Simulation-based optimization
Status: ResearchSearch over the space of actions using the simulation as the objective function. Under active investigation. Nothing is deployed, and no result is claimed.
Reasoning over the model, in the operation's own terms
Decision layer
The decision layer's job is to let an operations engineer interrogate the model without becoming a simulation engineer. It reasons over the operational model and the simulation results, which is what separates it from a language model with a dashboard bolted on.
Operational question answering over the model
Status: ResearchAsking where the constraint is, what a change would cost, or which of two interventions performs better, and having the question resolved against the model and the runs rather than against text. Under active investigation.
Scenario generation from an operational question
Status: ResearchTurning a stated intent into the set of scenarios that would answer it, then running them. Under active investigation.
Intervention comparison and trade-off analysis
Status: ResearchPresenting alternatives against the measures the operation is judged by, including the ones that trade against each other. Under active investigation.
Autonomous execution against the physical operation
Status: PlannedThe platform does not execute changes against a live operation, and no part of it is authorised to. Any future capability here belongs behind human authorisation, and safety functions stay on deterministic systems rather than on learned ones.
Keeping the model in step with the operation
Data and integration
A twin is only current because something keeps it current. The platform reads from the systems that already hold your operational data, and does not become a system of record for any of it. Every integration is scoped per deployment against the systems you actually run, and none of the connectors below is shipped as a finished product today.
Historical data import and calibration
Status: AvailableFiles, exports and database extracts of demand, cycle times, downtime and movement, used to calibrate the model and then to validate it against a period it was not fitted to.
Application and database integration
Status: AvailableREST, WebSocket and direct database connections, built per deployment. Demonstrated as an architecture by the mission twin, whose engine is driven entirely over its own API.
Industrial protocols: OPC UA, MQTT, Modbus
Status: PlannedScoped and delivered as integration engineering per site. No shipped connector exists today, and this entry will say otherwise only when one does.
SCADA, MES and ERP connectivity
Status: PlannedRead paths from the systems of record. Scoped per deployment, with the boundary agreed during Discovery. Anything already fully handled inside a SCADA or PLC layer is that layer's job and not the twin's.
Robotics telemetry as a twin input
Status: ResearchAutonomous systems returning the observations that keep a model current. This is the reason robotics sits inside this company rather than beside it.
Where it runs and who operates it
Deployment and operation
Deployment is on your infrastructure or in your cloud tenancy. The model, the runs and the operational data stay inside your boundary.
Self-hosted and private-cloud deployment
Status: AvailableThe deployment model is agreed during Discovery rather than assumed. Desktop, server and browser delivery are all in use across the public systems.
Operable by your own engineers
Status: AvailableScenario configuration, inputs and reporting built for your team to run without us. A model only its supplier can operate stops being used the moment the engagement ends.
Role-based access and audit
Status: PlannedScoped per deployment against your existing identity provider and access policy.
Multi-tenant hosted platform
Status: PlannedA hosted offering is a direction, not a product. Today every deployment is single-tenant and inside the customer's boundary.
The simulation platform underneath the engineering
Urual
Urual is an engine rather than an application. It owns users, projects, plugins, jobs, files, results and reports, and it knows nothing about a pallet, a gate, a bed or a gantry crane. Everything domain-specific lives in a plugin, which is what lets one execution layer serve models from unrelated industries.
Status: Prototype
Foundations are complete and the platform runs jobs end to end through its API. The MVP is in progress, it is not yet ready for production use, and no customer deployment runs on it. Engagements today are delivered as engineering; Urual is where that work is heading, not a product being sold ahead of itself.
The workflow a run passes through
Model
Status: PrototypeA domain lives in a plugin. The plugin declares what its inputs are and what it produces; the platform never learns what any of them mean.
Configure
Status: PrototypeA project holds input files. They are uploaded, hashed and validated twice: once by the engine against the contract, then by the plugin against its own rules.
Run
Status: PrototypeA job is submitted through the HTTP API and moves through a job state machine. A worker runtime picks it up and executes the plugin against the validated inputs.
Observe
Status: PrototypeJob state is readable while the run is in flight, through the same API that submitted it. The console renders what the API returns and holds no logic of its own.
Compare scenarios
Status: PlannedStructured comparison across runs is not in the platform today. Scenario comparison is demonstrated in the manufacturing twin, which instantiates complete additional plants and measures the difference, and bringing that into the platform is the intended path.
Analyze results
Status: PrototypeA completed job produces a result bundle: artifacts and reports, held in the storage subsystem and retrievable over the API.
Platform properties
HTTP API as the only interface
Status: PrototypeThe platform is driven entirely over HTTP. Every client, including the console and the Go SDK, is a translation of that API and holds no simulation logic.
Plugin system and SDK
Status: PrototypeDomain models are plugins built against a published contract. Adding an industry is an authoring job rather than a change to the platform.
Local execution
Status: PrototypeA local edition runs the engine entirely on one machine: no checkout, no subscription, no licensing, and no outbound network call. This is the deployment model that matters for operational data that may not leave a site.
Cloud execution
Status: PrototypeThe same engine with a worker runtime, object storage and Postgres behind it. In development alongside the rest of the platform.
Reproducibility
Status: PrototypeInputs are hashed on upload and a job records what it ran against, so a result can be traced back to the exact inputs that produced it.
Data isolation
Status: PrototypeProjects and files are owned by an account and scoped to it in the schema. This is the platform's own model, and it is not a substitute for the security review an enterprise deployment requires.
Model and result versioning
Status: PlannedVersioned models with a documented interchange format, so a model outlives the deployment it was first built in.
Role-based access control
Status: PlannedAccounts and ownership exist. Roles, per-project permissions and an audit trail do not, and an enterprise deployment would scope them against your identity provider.
FAQ
About the platform
What an evaluating engineer asks before spending an hour on the rest of this site.
What is the difference between this and a 3D model of our plant?
A 3D model holds geometry. An operational model holds objects, their states, the events that change them, the relationships that carry a change from one to another, and the constraints the operation cannot violate. Geometry tells you where a machine is. The operational model is what lets the system tell you that the machine is starved, why, and what relieving it would be worth. Three-dimensional views are an interface onto the model, and a useful deployment can exist without one.
Do we have to replace our SCADA, MES or ERP?
No. The twin reads from the systems that already hold your operational data and does not become a system of record for any of it. Anything already handled fully inside a SCADA or PLC layer stays that layer's responsibility. The integration boundary is set during Discovery against the systems you actually run.
Which integrations exist today?
Historical import, and application and database integration over REST, WebSocket and direct connections, are built per deployment today. Industrial protocol connectors and SCADA, MES and ERP read paths are labelled Planned on the platform page, and are delivered as integration engineering per site rather than as shipped connectors. The platform page lists every capability with its current stage.
Is the AI layer available?
No. The decision layer is labelled Research on the platform page and everywhere else on this site. The intent is narrow: an operations engineer asking a question in the operation's own terms and getting an answer resolved against the operational model and the simulation runs, with the assumptions attached. It is under investigation, nothing is deployed, and no part of the platform executes changes against a live operation.
How large a model can it run?
The published systems set a useful floor. The airport twin is built to a target of 10,000 passengers, 100 aircraft and 500 ground vehicles in real time; the manufacturing twin runs twenty-eight machines, thirty-eight people and four vehicles as one continuous model with a scenario lab that instantiates two further complete plants alongside it. The honest answer for a specific operation comes out of Discovery, because it depends on the model's structure rather than on a headline number.
Is the simulation deterministic?
Runs are seeded and inputs are versioned, so a given run reproduces exactly. The models are stochastic by design, because the variability is the thing being studied, so results are reported as distributions across replications rather than as single runs.
Where does it run, and who holds the data?
Deployment is on your infrastructure or in your cloud tenancy. The model, the runs and the operational data stay inside your boundary. Every deployment today is single-tenant; a multi-tenant hosted platform is labelled Planned.
What is Urual, and how does it relate to the platform?
Urual is the company's simulation engine: a headless, plugin-first, job-based runtime in Go with its own API, job state machine, worker runtime and artifact store. It is infrastructure rather than a competing product, it is in development, and it is not yet ready for production use. It is listed on the research page with that status.
Next step
Bring us an operation
Tell us what the system is and what decision it has to support. Alsadaany engineers will set out what a model would contain, what it depends on, and how it would be validated.
Prefer email? sales@alsadaany.com