Skip to main content
Alsadaany

Search this site

Search projects, services, pricing and frequently asked questions.

Site navigation

Technology

Capabilities, with the stage of each one

Organised by what the engineering actually does rather than by the tools it happens to use. Every entry carries its stage, and the entries that do not exist are listed as absent rather than left out.

How to read this page

Everything on this page exists in a repository this company controls, and carries the stage it has actually reached. Where something is genuinely absent, it is listed as absent rather than left out, because a gap a reader discovers later costs more than a gap they were told about.

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.

Capability group

Simulation

The methods the models are actually built from. Which one applies is decided by the mechanism that governs the system, not by preference.

  • Discrete-event simulation

    Status: Available

    Queueing, contention, blocking, starvation and failure as consequences of the model rather than parameters of it. The default method for production lines, warehouses and terminal processes.

    Manufacturing Operations Twin

  • Agent-based simulation

    Status: Available

    Populations of individuals with their own attributes, decisions and routing. Used where the behaviour of the population is what decides the outcome, as with passengers, operators and vehicle fleets.

    Airport Digital Twin

  • Coupled physical models

    Status: Demonstration

    Subsystems sharing state so a fault propagates through the physics rather than along a script. Demonstrated across orbit, power, thermal, attitude and communications.

    Satellite Mission Digital Twin

  • Seeded, replicated execution

    Status: Available

    Runs are seeded and inputs versioned, so a run reproduces exactly. Results are reported as distributions across replications, because one run of a stochastic model is a sample rather than an answer.

    Method

  • Monte Carlo analysis

    Status: Available

    Repeated replication under sampled inputs to characterise the spread of an outcome rather than its central case. Delivered as part of an engagement; it is a way of running the models above, not a separate engine.

  • Spiking neural network simulation

    Status: Research

    Reconstructed connectomes executed as running spiking networks, with circuits that can be driven, recorded and ablated. Research infrastructure rather than an industrial method.

    NeuroSim

Capability group

Digital twins

What turns a simulation into a twin: a structured model of a specific operation, and something that keeps it in step with the real one.

  • Operational model and ontology

    Status: Available

    Objects, relationships, states, events, constraints and actions, in the terms the operation uses. Built with the people who run it, because a model no domain expert has checked is a model of an assumption.

    The operational model

  • Calibration and out-of-sample validation

    Status: Available

    Fitted on one period of operational history and tested against another it never saw, with the deviation reported rather than summarised.

    Validate

  • Model definitions as data

    Status: Demonstration

    Plants and terminals are generated at runtime from layout and equipment data, so a second facility is a second dataset rather than a second build.

    Airport Digital Twin

  • Scenario management and comparison

    Status: Demonstration

    Alternatives run from an identical starting state and compared on measured outcomes. Demonstrated by instantiating complete additional plants; not yet a platform feature.

    Scenario comparison

  • Historical data ingestion

    Status: Available

    Files, exports and database extracts of demand, cycle times, downtime and movement, used to calibrate and then to validate.

  • Real-time state synchronisation

    Status: Planned

    Live read paths that keep a deployed twin current. Delivered as integration engineering per site; no shipped connector exists, and this entry will say otherwise only when one does.

    Integrations

Capability group

Visualization

An interface onto the model. It is how a result is read, and it is never where a number comes from.

  • Real-time 3D environments

    Status: Demonstration

    Unity 6 with the universal render pipeline, generating the environment at runtime from layout data rather than from an authored scene.

    Public systems

  • Crowd rendering at operational scale

    Status: Demonstration

    Burst-compiled jobs over struct-of-arrays storage with spatial-grid neighbour avoidance, GPU instancing and three distance levels of detail. The crowd costs a handful of draw calls rather than ten thousand scene objects.

    Airport Digital Twin

  • Browser delivery

    Status: Demonstration

    WebGL builds with an explicit performance budget per target, trimmed deliberately rather than degrading unpredictably.

    Run the systems

  • Operator interfaces and reporting

    Status: Available

    TypeScript and React surfaces over model state, with control panels generated from a parameter registry so an interface cannot drift from what it controls.

Capability group

Infrastructure

What executes a model, stores what it produced, and lets another system drive it.

  • Headless engine with an HTTP API

    Status: Prototype

    Urual: a job state machine, a worker runtime, a plugin system, storage and artifacts, and a Postgres schema behind all of it. Driven entirely over HTTP.

    Urual

  • Engine and viewer separation

    Status: Demonstration

    The engine owns simulation state and every client is a viewer. Enforced across a process boundary in the mission twin, where the client computes no physics and says so when the engine stops.

    Satellite Mission Digital Twin

  • Typed API client

    Status: Prototype

    A Go SDK that is a translation of the platform's HTTP API and nothing more: no simulation logic, no plugin knowledge, no state beyond a session.

  • Local execution

    Status: Prototype

    The engine running entirely on one machine, with no checkout, no licensing and no outbound network call. This is the deployment model for operational data that may not leave a site.

    Urual

  • Containerised environments

    Status: Available

    Docker and Docker Compose for reproducible engine environments, in use across the platform and the Python simulation engines.

  • Automated test suites over engine behaviour

    Status: Available

    Tests written against what the model computes rather than against the interface. The mission twin's engine carries 198 of them.

    Satellite Mission Digital Twin

Capability group

AI and optimization

This group is short, and it is short because almost none of it is implemented. Optimization and decision support are the direction the platform is heading; publishing them as capability would be the single most damaging thing on this page.

  • Constraint identification

    Status: Demonstration

    The binding constraint derived analytically from stage capacity and corroborated independently by queue depth. This is analysis over model state, not a learned model, and calling it AI would be a category error.

    Manufacturing Operations Twin

  • Rule-based autonomy

    Status: Demonstration

    Protective behaviour that emerges from state crossing a threshold rather than from a timeline: load shedding, downlink inhibit and safe-mode entry in the mission twin. Deterministic by design.

    Satellite Mission Digital Twin

  • Parameter sweeps and design of experiments

    Status: Planned

    Systematic exploration across a defined parameter space, distributed over the execution engine. Depends on the platform reaching the point where large run sets can be scheduled and compared.

  • Simulation-based optimization

    Status: Research

    Search over the space of operational actions using the simulation as the objective function. Under investigation. Nothing is deployed and no result is claimed.

    Research

  • Operational reasoning over the model

    Status: Research

    An engineer asking a question in the operation's own terms and getting an answer resolved against the model and the runs, with the assumptions attached. Under investigation, and it executes nothing.

    Research

  • Computer vision and machine learning

    Status: Planned

    Alsadaany operates no trained model in any delivered system today. Terra's product direction depends on vision and sensor fusion, and that work is ahead of the company rather than behind it. It is listed here so its absence is explicit rather than inferred from silence.

Next step

Bring us a system

The useful conversation is about the mechanism that governs your operation and which method actually fits it. That is a question our engineers can answer in one call.

Prefer email? sales@alsadaany.com