Emergency planners at an Israeli critical-infrastructure resilience company can now load a national asset catalog, drop a failure scenario on it, and watch the effects spread through the network in 15-minute steps. They see which substations, pipelines and customers lose supply, for how long, and why.
The client models how a national emergency, such as an earthquake or an attack on a facility, would spread through critical infrastructure. Their inputs were spreadsheets, one per asset type and sector, each with its own columns. Coordinates came in three notations, map geometry came as KMZ files, and there was no model of which asset feeds which.
Answering “if this transformer loses 40% of its capacity at 08:15, which customers go dark, and when do they come back?” meant reasoning by hand over disconnected files.
The diagram is wider than the screen: swipe sideways to see all of it →
ETL output lands in a separate staging database first. Nothing reaches the catalog the simulation reads until it has passed validation and the transactional sync. The simulation loads the asset graph into memory once, then writes results in one batch per step.
This is a small synthetic network that follows the engine's rules. None of the names, values or topology come from the client. Pick a step to see what the engine changes and which follow-up events it schedules.
Talend writes to its own staging database. A single stored procedure runs 20 per-type MERGE syncs inside one transaction. A failed refresh leaves the catalog exactly as it was. The trade-off is a second copy of the 57 catalog tables, which has to be kept in step with the main schema.
Generators, transformers, lines, customer loads and gas assets each have their own strategy class behind one interface, with a default for types not modelled yet. Adding the gas sector meant writing a new strategy, not changing the engine. The trade-off is that cross-sector coupling is modelled through dependency links, not a combined physics solver.
Each step sorts the asset graph topologically. A reverse pass pushes demand upstream, then a forward pass pushes supply downstream. It's fast and easy to explain to planners. The trade-off is that it approximates the electrical behavior rather than solving full load flow.
A failure with a repair time schedules its own recovery. A generator start schedules “online” after its startup time, and a load on battery schedules its depletion. Planners write only the first event. The engine produces the timeline and saves every event it generates.
Point and line geometry, and their GeoJSON, are computed when data is synced or edited and stored on the asset. A map request is a spatial intersect with the visible rectangle, followed by string concatenation of the stored GeoJSON. The trade-off is that every edit path has to recompute geometry, so that lives in one service method.
Each asset type had its own columns, units and lookup values. Writing a separate import and API for each one would not have scaled.
Built a generic catalog layer: base controller and storage, one Excel import and export utility, and one mapping profile. A new asset type needed an entity and its mappings, not new plumbing.
The Talend jobs are standalone exported scripts. A web request had to start them, wait for them, and not leave orphan processes behind when someone cancelled.
The API starts each job as a child process with an OS-specific launcher, waits asynchronously, and kills the whole process tree on cancel. A failure in one sector is logged and the other sectors keep running.
Source sheets mixed degrees-minutes-seconds, degrees with decimal minutes, and decimal degrees.
ETL routines convert all three to decimal degrees and validate them. From March 2025, rows that fail validation are written to an invalid-rows table with the reason, so the job no longer stops or silently drops them.
The first map read a static GeoJSON file. Real voltage lines and pipelines are polylines with many vertices, and the map file's line styling had to survive the import.
Converted points and polylines to SQL Server geometry, stored GeoJSON on each asset, and served the map through a viewport-intersect query. KMZ import matches assets by external ID with one batched lookup and one bulk update.
Large read queries with several includes were loaded into the EF change tracker even though nothing would be saved.
Switched those read paths to no-tracking with identity resolution. Related entities stay de-duplicated, without the tracking overhead.
A transformer's required input depends on what its downstream loads need, but its output depends on what its upstream supply delivers. Calculating assets in arbitrary order gave results that depended on that order.
Engine v2 topologically sorts the graph and runs two passes on every step: reverse for demand, forward for supply. Events are grouped per asset and processed before recalculation.
The run list showed a current step that never matched the total, so finished runs looked stuck.
Aligned the step-count formula between the service and the engine. Each step now also records CPU, memory and elapsed time, so slow runs can be explained.
Planners kept failure events and asset constraints in separate files, which made runs easy to set up inconsistently.
One combined workbook import for scenario and constraints, a results-by-step API, and chain views (tree, Sankey and force graph) showing how a failure travels.
| Area | Before | After |
|---|---|---|
| Data refresh | Per-type spreadsheets, processed job by job | One action runs 40 ETL jobs, a transactional sync, geometry and connections |
| Bad source rows | Rows rejected without a record | Row kept in an invalid-rows table with the reason |
| Map | Static, pre-parsed GeoJSON file | Live viewport query on SQL geometry, always current with the catalog |
| KMZ import | A per-asset approach: ≈2 database calls per asset | 2 calls per file: one batched lookup, one bulk update |
| What-if analysis | Reasoning by hand over disconnected files | 15-minute steps, 24 h in ≈1.6 min, per-asset results, dependency chains and Excel export |
| Live run page | Polling every second would mean 60 status calls a minute | 3 calls a minute (a 20 s poll, stale requests aborted) plus a local 1 s clock |
Free scoping call · 30 minutes · No commitment
Write a few lines: the process or system, what hurts today (time, errors, cost or an AI pilot that stalled) and who uses it. After a short call you get a written plan and a fixed quote within ≈3 days.
Opens a pre-filled email · reply within one business day
The model reads. The code counts.
All projects