FabAssurance is the semiconductor arm of Adaps Group. We bring breakthrough semiconductor technology to the customers who need it, including new memory architectures, process control, inspection and metrology, and supply the engineering, testing and support that turn it into something running in production for years. Wherever you build.
What we bring
The model
A global technology company can sell into a new market. What it usually cannot do is staff the evaluation, the integration, the validation and the years of support that follow — in every region, for every customer. The customer sees the mirror image: a good product, and nobody local to make it work or keep it working. That gap is where we operate, on both sides of it.
Technology vendor covers
Evaluate
Benchmark on your own workload
Integrate
Integration and commissioning
Validate
Acceptance, migration and DR testing
Operate
24×7 monitoring, L2 / L3 sustenance
Evolve
Upgrades, migration, retrofit
Continuous — one accountable party, one contract, one escalation path
The product is rarely the problem. The uncovered spans are — and they are where a deployment quietly fails.
For the technology vendor or OEM
For the fab, OSAT or customer
Why now
This is not a regional story. Capacity is going up on four continents, mature nodes are growing alongside the leading edge, the people who can bring new technology into production are scarce everywhere at once — and what a facility consumes and reports is now part of whether it gets built and who will buy from it.
US$133B
global 300mm fab equipment spend, 2026
SEMI projects global 300mm fab equipment spending at US$133 billion in 2026 and US$151 billion in 2027 — around US$374 billion across three years, driven by AI demand. New facilities are under construction across the Americas, Europe, Japan, Korea, Taiwan, China and India.
Every one of them buys technology from companies with no delivery arm on the ground.
US$7.7B
200mm equipment spend, 2026
SEMI puts 200mm equipment spending at US$7.7 billion in 2026, up around 10% year on year, with installed capacity near 7.7 million wafer starts per month and five new volume 200mm fabs starting this year. Power, analog, MEMS and MCU demand is holding that base up, not letting it decline.
Much of that installed base predates the standards it is now expected to speak.
1 million
additional skilled workers by 2030
Deloitte estimates the industry needs around one million additional skilled workers globally by 2030. The specialist vendors serving fabs are small — tens of millions in revenue, low hundreds of staff — and are limited by scarce engineers rather than by demand for what they sell.
In 2026 a major EDA vendor discontinued its equipment-engineering and fault-detection line, leaving those fabs to migrate or self-maintain.
62%
of upstream Scope 3, from purchased materials
Fabs are among the most water- and energy-intensive industrial sites there are, and siting decisions increasingly turn on whether a region can supply both. Meanwhile most of a chip company's footprint sits outside its own walls: McKinsey attributes 62% of upstream Scope 3 emissions to purchased materials — chemicals, wafers and gases. Reporting that means collecting from hundreds of suppliers, not reading your own meter.
Disclosure has moved from reputation to procurement condition, and from annual report to audited data.
Services
They are deliberately ordinary software engineering disciplines, applied under a fab's constraints. What is scarce is not the discipline — it is anyone willing to do it properly, in-region, for years.
Testing, in detail
Every deployment of somebody else's product raises the same question: how do you know it works, here, on your data, under your conditions? Answering that with evidence rather than assertion is the discipline this business was built on, and it is the thread running through everything else on this page.
| Test type | The question it answers | Typical trigger |
|---|---|---|
| Acceptance | Does the delivered system meet the specification we agreed, clause by clause, before anyone signs? | New product, factory or site acceptance |
| Migration | Did every record arrive intact, do old and new agree in a parallel run, and can we rehearse the cutover before we do it for real? | MES or platform replacement |
| Disaster recovery | When the primary fails, does failover actually work, does it meet the recovery objectives on paper, and is the runbook correct? | Audit, insurer, customer requirement |
| Conformance | Does this interface behave the way the SEMI standard specifies — not the way the vendor's documentation summarises it? | Equipment integration, OEM shipment |
| Regression | Did this release break something that used to work? | Every build, not every milestone |
| Performance & volume | Does it hold up at production data rates rather than at demo scale? | Ramp, capacity expansion |
| Integration | Does the new product coexist with everything already installed, including the things nobody documented? | Any new vendor in a live stack |
Each of these produces an evidence pack — what was tested, against which clause or requirement, with what result. It exists to be handed to your customer, your auditor or your insurer, not filed.
The continuum
Ten to twenty billion dollars of plant earns nothing on a day it is stopped, and a surprising number of things can stop it that have nothing to do with whether the process works. Most of them are small at the moment they happen. The list below is what we are actually selling against — not a category, a set of specific ways a capital-intensive plant loses time, capability or its licence to operate.
| What goes wrong | Why it bites harder here | What we bring to it |
|---|---|---|
| A release breaks something | Host and MES software touches every lot on the floor; a bad release can halt or misroute work in progress | Regression and acceptance testing, run per build rather than per milestone |
| An interface drifts from spec | Equipment stops reporting correctly and data quality degrades quietly, long before anyone notices | SEMI conformance testing against host and equipment simulators |
| A migration loses data | Cutover is the highest-risk night in a plant's software life, and it is rarely rehearsed | Migration testing: reconciliation, parallel run, cutover rehearsal |
| Failover has never been tried | A recovery plan that has not been exercised is an assumption, and the audit will ask | Disaster recovery testing, RTO and RPO verification, runbook validation |
| An alert goes unwatched | Small anomalies become excursions; excursions become scrapped lots and lost weeks | 24×7 monitored operations, playbook triage, 30-minute critical response |
| A safety or environmental incident | One event can stop a line, trigger an investigation and put a permit in question | Incident, hazard and EHS management platforms, deployed and run |
| A contractor event during build | Thousands of contractors on a live site are the highest-risk population on the property | Contractor and workforce compliance systems |
| A supplier fails | Most of the footprint, and much of the operational risk, sits upstream rather than inside the fence | Third-party and supply chain risk management |
| An audit or qualification fails | Automotive and aerospace customers audit hard; losing qualification loses the account, not just the order | Policy, controls, internal audit and audit-ready evidence |
| A disclosure obligation is missed | Sustainability reporting has moved from annual report to procurement condition | CSRD and sustainability reporting platforms |
| The continuity plan is a document | Business continuity only exists if it has been tested against something real | Business continuity management, and the testing that proves it |
Read the column on the right and you have our portfolio. We did not assemble it from a market map — it accumulated because these are the things that stop plants, and the same firm is well placed to test them, watch them and carry the software that governs them.
The technology we bring
The industry does not lack breakthroughs. It lacks the work between a breakthrough and a production system — the benchmarking, the integration, the testing, the years of support. We choose what we carry on one test: does it need real engineering to land? Where it does, we are worth more than a distributor, because we supply that engineering ourselves. What we carry spans the fab floor, the instruments that watch it, and the obligations that surround it.
We are not a reseller putting a brochure on the table. When we bring a technology to you, the people who built it are in the room: their engineers answer for the product, ours answer for the deployment. You get both halves of the conversation at once, and a proof of concept run on your workload rather than a reference one. What you conclude from it is entirely yours.
Technology that changes what the plant or the workload can do.
An architectural shift rather than an incremental one. Blueshift's Cambridge Architecture™ attacks the memory bottleneck at the controller — the constraint that increasingly decides what an AI or HPC workload can actually do — and is independent of the underlying memory cell technology. It is available as controller IP, as CXL and PCIe accelerator boards, or integrated into an SoC alongside a CPU, GPU or AI engine. Published gains run to orders of magnitude on memory-bound workloads, with substantial energy savings alongside.
Benchmarking on your own workload alongside Blueshift's engineers, integration into your platform, acceptance testing, and sustaining support afterwards — roughly two to four months of engineering per deployment, before a single day of production use.
Inspection, metrology and the yield analytics software alongside them — the instruments a fab, OSAT or packaging line depends on from first silicon, because yield is decided by what you can see and how fast you can see it. We run 24×7 monitored operations for this company from October 2026: we support the software before we ever put the product in front of a customer.
Every facility coming up needs these systems integrated, validated and supported locally — work no instrument supplier wants to staff site by site, anywhere in the world.
This relationship began with us running their applications. A technology company that has watched an engineering firm operate its software for months is the most informed possible judge of whether that firm should carry its products.
Software that governs the risks which stop a plant or cost it a licence.
An established governance, risk and compliance platform with an EHS portfolio alongside it — used by around a third of the Fortune 500, across roughly five million users. We worked with SAI360 for six to seven years as a customer of the platform before becoming a partner in it, and are now its exclusive services provider for the GRC and EHS portfolio. We know where this software is difficult, because we ran it ourselves first.
Implementation and configuration, integration into the systems already running, migration from legacy or spreadsheet-based processes, acceptance testing against the obligations that actually apply, user enablement, and ongoing support — as SAI360's exclusive services provider for this portfolio.
A portfolio of enterprise sustainability, health-and-safety and compliance platforms — Nexo CS, QMED, iSystain, PeopleTray and Zyght — proven across mining, energy, construction and logistics. Those are the industries that had to solve industrial environmental and safety reporting first, under regulators who audit it. Where SAI360 governs risk at the enterprise level, these platforms live at site level — the contractor at the gate, the permit on the wall, the incident on the floor. Semiconductor now carries the same obligations, with a heavier chemical inventory, a bigger water and power draw, and construction running on four continents at once.
Deployment and integration into the EHS, ERP and plant systems already in place, migration off spreadsheets and legacy tools, acceptance testing against the disclosure obligations that apply to you, and running it afterwards.
We are in conversation with further technology companies across fab software, instrumentation and infrastructure. The test never changes: if a product can be shipped, installed and forgotten, it does not need us. If it needs engineering to land and engineering to keep working, we are the reason it succeeds in a market rather than stalling in it.
Where we sit
On the fab software side specifically, it is worth being precise about which layers we work on. We are not a connectivity vendor and not a process engineering firm.
Fab software stack
Detects excursions. Depends entirely on the data the layers below emit.
Opcenter, SmartFactory, Critical Manufacturing, Eyelit, or something home-grown.
Per-tool logic. Built once, changed constantly, rarely fully staffed.
Commercial toolkits. Entrenched, and we are not trying to replace them.
On a 200mm line, often older than the standards it is asked to speak.
Where we engage
Conformance, regression, acceptance — off-site.
24×7 monitoring, L2/L3 sustenance.
Legacy MES moves, 200mm retrofit work.
Events, alarms and trace data flow upward. Recipes, remote commands and job control flow downward.
A gap at any layer surfaces as an excursion no one at the top can explain.
Standards
Vendors routinely present these as one family. They are not: some define transport, one defines syntax, one defines behaviour, several define objects, and two define measurement rather than communication. Getting this distinction right is the cheapest possible proof that someone has read the material.
| Standard | Layer | What it specifies |
|---|---|---|
| E4 · SECS-I | Transport | Block transfer over RS-232 serial. Largely displaced by HSMS, but still the only interface on much older equipment. |
| E5 · SECS-II | Syntax | Message content: streams and functions, data item types, nested lists, expected replies. Defines structure — not what a tool must do. |
| E37 · HSMS | Transport | Carries SECS-II over TCP/IP. Session establishment, link management, error detection. HSMS-SS is the profile in real-world use; HSMS-GS is withdrawn. |
| E30 · GEM | Behaviour | The behavioural contract: control state models, status variables, collection events, alarms, remote commands, recipe management, spooling. This is where "GEM-compliant" means something. |
| E39 / E40 | Objects | Object services, and process job management — the material list plus recipe that constitutes a job. |
| E87 | Objects | Carrier management: carriers, load ports, access modes. Substrates become available only once the carrier ID and slot map are read and validated. |
| E90 / E94 | Objects | Substrate tracking, and control job management — the supervisory layer over process jobs, including queue reordering for priority lots. |
| E116 · EPT | Measurement | Equipment performance tracking at equipment and module level: state changes, time in state, blocked reasons. No operator or host input required. |
| E10 · RAM | Measurement | Not a communications standard. Six basic equipment states and the reliability, availability and utilisation metrics built on them. Implemented in reporting, not in a driver. |
| E120 / E125 / E164 | EDA | Interface A, not GEM300: the common equipment model, equipment self-description, and the common metadata that lets a client write one data collection plan across unlike tools. |
| E84 | Hardware I/O | Not a SECS message protocol. The optical signal handshake between material handling and the load port. The host triggers handoff through E87; it does not drive E84 directly. |
| E187 / E188 | Security | Cybersecurity for fab equipment: OS and network hardening, endpoint protection and monitoring, and malware-free procedures through delivery, installation and maintenance. Increasingly a procurement condition. |
Two consequences worth stating plainly. Nothing in the GEM300 set is substrate-size specific — the standards say "substrate" and "carrier" deliberately. And E116 and E10 are arguably more valuable on a 200mm line than a 300mm one, because tool availability, not throughput, is the binding constraint there.
How we deliver
Recipes and process data are a fab's crown jewels. Every offshore engineering proposal in this industry dies on that point unless the delivery model answers it first. Ours does.
Standing
A new name on a sixty-year-old firm. Six decades of engineering, a testing practice that is the origin of the business, a signed semiconductor operations contract, and an offshore centre built for multi-year delivery.
Since 1964
FabAssurance is the semiconductor arm of Adaps Group — a family-owned engineering and managed services firm with six decades of continuous operation, headquartered in Melbourne with entities in Australia, Singapore, India and the United States.
Operating in semiconductor
A signed agreement with a US-listed process control and metrology supplier for 24×7 monitored operations — playbook-driven alert monitoring and triage on a Linux, Grafana and Vertica stack, to a 30-minute critical response commitment. Service goes live in October 2026.
Testing is the business
Quality assurance is the firm's origin discipline, not an add-on. We run migration and acceptance test programmes for enterprise systems where a failed release has operational consequences, and we have our own platform work in automated test generation and traceability.
Offshore at scale
A Hyderabad engineering centre under its own head of engineering, built for sustained multi-year delivery rather than project staffing — which is what sustaining engineering actually requires.
Product direction
Two things we are building, shown here as direction. We are looking for design partners who would rather shape one than wait for it.
Seeking partners
Conformance testing today is a milestone event: run before a shipment, documented once, and stale by the next release. It should be a build step.
Seeking two design partners: one equipment maker, one fab.
In exploration
Bringing a pre-standard 200mm tool onto a modern host is repeatable work that is currently redone from scratch every time.
Complements the connectivity vendors. Does not compete with them.
Let's talk
You have technology and no delivery arm in the market you are entering. You want a breakthrough proven on your own workload before you commit. Or you are running systems with more backlog than engineers. Any of those, we should talk.
One note, and only one
Every deployment is different, and results vary with workload, configuration and environment. Performance figures for the technologies we carry are the manufacturers' own. We will not oversell them and we will not ask you to take them on trust: confirm anything that matters through your own proof of concept, or through independent verification with the manufacturer. We will help you run that evaluation, with their engineers alongside ours. The conclusion is yours to draw.