Review of InterDynamics, Simulation and Fatigue-Risk Software Vendor

By Léon Levinas-Ménard

Last updated: November 4, 2026

InterDynamics develops Planimate, a simulation environment for modeling industrial operations, and builds custom decision-support applications with it. Its logistics work covers mines, railways, stockyards, ports, equipment, and scheduling. Supply Chain Sim provides a packaged network-modeling application. The company also sells FAID Quantum, a separate product for assessing fatigue exposure from work schedules. 1 2 3 20

Overall supply chain score: 5.5/10.

Dimension	Score
Supply chain depth	4.8/10
Decision and optimization substance	5.4/10
Product and architecture integrity	6.0/10
Technical transparency	5.8/10
Vendor seriousness	5.6/10

InterDynamics models interacting physical constraints at the scale of a pit-to-port operation. Its technical reference exposes distributions, programmable routines, batch execution, and integration with other software. 4 6 7 14 17

The principal weakness is the gap between simulating a proposed plan and producing economically good decisions. Distributions entered by modelers do not establish calibrated forecasts; a range of simulated outcomes does not identify the best use of capital. The published operating model remains a specialist project in which people specify assumptions, construct scenarios, interpret results, and maintain the representation of the business. 5 8 9

InterDynamics versus Lokad

Consider a miner deciding how to coordinate production, trains, stockpiles, and vessels. InterDynamics can represent the physical interactions and simulate what a proposed operating plan would do. Queues, equipment failures, maintenance windows, and blending requirements can affect one another within the same model. 4

Lokad’s inventory optimization service produces recurring decisions from their expected economic consequences under uncertain demand and supply. Supply Chain Scientists maintain the numerical logic and data preparation; their work belongs in the cost comparison alongside InterDynamics’ model development and operation services. The perspective presented in Introduction to Supply Chain emphasizes an economic system: recurring decisions should be generated programmatically, while specialists improve the assumptions and logic that produce them.

A simulation can be a useful part of that work. It can reveal that one additional train creates congestion rather than throughput, or that maintenance timing matters more than another piece of equipment. It does not, by itself, decide whether a change is worth its purchase cost, operating expense, inventory exposure, and effect on future sales. Those valuations and the search for better decisions must be designed separately.

InterDynamics’ published monthly-planning example maximizes shipping volume through scenario testing. That objective can be useful for a constrained bulk operation, but throughput is still a proxy for economic return. Product value, quality penalties, demurrage, and the opportunity cost of assets can make two plans with equal volume materially different. The public explanation does not expose that complete valuation. 5

Product history and technical continuity

Period	Documented development	Significance
1989–1999	InterDynamics dates Planimate’s origin to 1989, the company to 1992, and FAID to 1999. 1	Simulation and fatigue assessment are longstanding product lines.
2012	Release notes detailed train-length modeling, data-driven track construction, external functions, and a command-line build for Linux and Android. 10	Development addressed operational modeling and integration rather than a sequence of changing technology labels.
2013–2014	Planimate added routine import/export as text and parallel embedded instances; its DLL API exposed run control, callbacks, and data access. 11 15	Programmatic use has a long technical history, despite the prominent graphical interface.
2016	FAID Quantum added a second biomathematical model. A separate Planimate reference documented .NET interoperability. 16 20	Distinct product capabilities were extended through identifiable mechanisms.
2020	Version 11 introduced a new licensing system, Unicode support, interface improvements, and revised compilation options. Version 12 development included conveyors and pausable processing objects. 12	The modeling environment continued to evolve through concrete features.
2023–2026	FAID gained a web application, with a current public guide covering group roles, schedules, and analysis. 21 22 23	The fatigue application has its own delivery model; its web interface does not describe the architecture of Planimate logistics projects.

The roadmap has recognizable continuity. The weakness in the public record is its uneven maintenance: detailed old interfaces remain accessible alongside newer product pages, without a consolidated statement of current supported combinations. Some of that older documentation also contains elementary statistical errors, discussed below. An established product still needs current, accurate explanations of its numerical behavior.

What the simulation represents

A connected physical system

The BHP case describes seven mines, more than a thousand kilometers of railway, and two port facilities. The model includes train loading and unloading, rail movement, stockyard handling, blending, shiploading, and channel operations. Equipment availability, processing-rate variation, planned maintenance, and unplanned maintenance are configurable. Users can test changes to rail capacity, train composition, stockpile allocation, and operating rules. 4

These interactions matter. A faster mine can move the bottleneck to a rail loop; more train capacity can overwhelm unloading; a different stockpile allocation can alter blending and shiploading. Modeling each asset independently would miss such effects. The case supports a system-level simulation capability, although its claimed improvement in planning accuracy is not accompanied by a numerical evaluation. 4

The 2023 monthly-planning article explains the operating sequence. Planners provide production capabilities, rolling stock, rail restrictions, maintenance, inventory, and shipping plans. Processes vary according to historical behavior; repeated runs use different random seeds. Users then change scenarios to assess operational adjustments and disruptions. 5

Sampling assumptions is not forecasting them

Planimate’s distribution dialog supports common continuous distributions and user-supplied probability tables, including discrete outcomes and cumulative distributions. This allows variation to be attached to arrivals, processing times, and other modeled events. 6

That is the basic machinery for Monte Carlo simulation. The difficult work is determining which distributions remain predictive, how events depend on one another, and how decisions change the possible outcomes. Drawing more samples from an unrealistic model produces a more stable estimate of the wrong answer. For a connected logistics operation, common causes such as weather, workforce availability, and upstream disruption can affect several processes together.

The public descriptions do not explain how a delivered model estimates and updates these dependencies, validates demand and supply distributions, or evaluates its forecasts outside the period used to build it. Historical variability is a starting point, not a guarantee that next month’s operating conditions follow the same pattern. 5 6

The distribution guide, last modified in 2010, also says 95% of normally distributed draws lie within three standard deviations. The correct normal-distribution figure is about 99.73%; roughly 95% lie within two standard deviations. It also describes the exponential waiting-time distribution as if interchangeable with a Poisson count distribution. These are errors in the published explanation, not evidence that the random-number implementation uses the wrong formulas. They nevertheless weaken a document meant to guide users in representing uncertainty. 6

A digital twin needs a forecast test

InterDynamics markets simulation as a way to build a digital twin. Once the model projects queues, inventories, throughput, and equipment states through time, it is making many linked forecasts. More animated detail increases the number of assumptions requiring validation. 2

Matching average historical throughput is insufficient. A useful validation should examine inventory trajectories, queue-duration tails, congestion episodes, and recovery after disruptions at the horizons relevant to planning. It should also test whether the model correctly ranks proposed changes. A model can reproduce the past with compensating errors and still recommend the wrong investment.

The BHP description identifies the relevant physical mechanisms, but supplies no held-out comparison of predicted and observed outcomes or measured economic return. The monthly-planning account reports more stable operations and lower demurrage without quantifying the contribution. 4 5

Software materials and execution architecture

Component or mechanism	Public evidence and scope
Standalone Planimate runtime	The published system requirements describe a Windows executable that does not require .NET or administrator rights; optional applications can add dependencies. The page still lists legacy Windows versions and specifications. 13
Planimate model language	The routine reference exposes calculations, tables, file operations, routing, and other programmable operations. 7
Embedded simulation	The 2014 DLL API describes a native loader and Win32 C++ sample, with independent simulation instances and callbacks. 15
.NET integration	The public PL.Net repository supplies a C# wrapper. The 2016 interop reference describes calling .NET assemblies and passing data between them and a model. 14 16
Noninteractive execution	Command-line documentation describes batch runs without graphics. The 2013 release review also documents text import/export of routines. 11 17

The standalone core keeps infrastructure requirements modest. The main complexity lies in the customer-specific model and the effort needed to understand or change it. 8 13

A developer can embed simulations, supply data, advance execution, and retrieve results. Deploying an unattended decision service requires additional scheduling, input validation, failure recovery, decision publication, and regression testing. 14 15 17

Planimate’s own runtime remains proprietary. The open wrapper makes integration more inspectable but does not let a customer reproduce the simulation engine elsewhere. The 2020 release describes perpetual developer licensing and compiled applications that can run without a separate license; the older public licence page retains annual subscription levels. Those documents require reconciliation for a current deployment and its long-term maintenance rights. 12 14 19

Model maintenance and productivity

InterDynamics’ development approach explicitly captures the customer’s processes, business logic, and decision rules. Projects proceed through staged prototypes, with users confirming direction and testing successive builds. The company also offers to operate models, run scenarios, analyze outputs, and produce reports for customers lacking the staff or skills. 8 9

The central ownership cost is therefore the model’s lifecycle. Every new loading rule, product grade, rail restriction, maintenance regime, and data interface can require a change. A visually plausible model can continue running after its assumptions have become obsolete. The cost of detecting that drift, revising the logic, and validating the result belongs in the project economics.

Supply Chain Sim makes part of the tradeoff explicit. Its packaged interface allows users to alter locations, fleets, products, and process variation, while the published professional tier limits the number of modeled locations and products. These are limits of that application, not of custom Planimate models. Standardization reduces development effort within the represented problem; more unusual operating logic returns the customer to custom development. 3

Agent-assisted coding could accelerate changes to exported routines and surrounding integrations. The harder productivity test is whether a specialist can revise and safely redeploy the model after an operational failure. No public case quantifies that improvement cycle, model-maintenance hours, or recurring decisions generated per employee. Interactive scenario exploration remains the clearest documented use. 5 8 11

Security and responsibility boundaries

A Planimate model is executable logic. The routine reference includes file deletion and writing, while the extension documentation allows model code to invoke user-supplied native DLLs and .NET assemblies. The documented extension boundary therefore matters when a model has access to production files or credentials. Interface type checking is not a sandbox restricting what the loaded code can do. 7 16 18

The reviewed material does not describe restrictions on extension privileges, outbound access, or dependencies that would contain a compromised library or a serious coding mistake. A customer integrating these facilities into production needs a controlled execution environment; the graphical modeling interface does not provide that protection by itself. The published reference describes developer extensibility, not a default cloud service accepting arbitrary customer code. 13 16 18

FAID Quantum Web has a separate boundary. Its current guide defines group administrators, managers, and users, with permissions over settings and schedules. It also assigns the selection of fatigue tolerance levels to the user. Those roles and parameters concern the fatigue application; they do not establish isolation for a custom logistics model. 22

Economic responsibility is also mainly project-based. The supplier participates in scoping and iterative validation, but the public case does not define a financial baseline, full model-maintenance cost, or remedy if expected benefits fail to materialize. The published Planimate licence excludes liability for lost savings and profits. That leaves model quality and acceptance criteria especially important in the implementation agreement. 8 19

Supply chain score

Supply chain depth

Criterion	Score
Economic framing	4/10
Decision end-state	5/10
Conceptual sharpness on supply chain	6/10
Freedom from obsolete doctrinal centerpieces	5/10
Robustness against KPI theater	4/10

Average: 4.8/10.

Economic framing — 4/10. Capacity and delay costs are relevant, but the published planning example emphasizes volume. The method for valuing competing operational choices in money remains customer-specific and undisclosed. 5 8

Decision end-state — 5/10. A proposed capacity change or monthly operating plan is concrete. Most of the documented work still ends with a specialist interpreting alternatives rather than a recurring decision stream. 5 9

Conceptual sharpness on supply chain — 6/10. The model recognizes that local improvements can fail at interfaces elsewhere in the operation. That whole-system perspective is a substantive strength. 4 9

Freedom from obsolete doctrinal centerpieces — 5/10. Physical interactions and variability give the analysis more substance than a target dashboard. The human scenario-selection process can nevertheless become a costly ritual unless tied to consequential choices. 5 8

Robustness against KPI theater — 4/10. Operational outputs are meaningful, but greater throughput or better-looking simulated performance is not sufficient evidence of economic benefit. Published cases do not establish that final link. 4 5

Decision and optimization substance

Criterion	Score
Probabilistic modeling depth	5/10
Distinctive optimization or ML substance	6/10
Real-world constraint handling	7/10
Decision automation and labor productivity	4/10
Resilience under real operational complexity	5/10

Average: 5.4/10.

Probabilistic modeling depth — 5/10. Variation can propagate through a connected operation. The missing evidence concerns how those inputs are forecast, calibrated, and updated together, rather than merely sampled. 5 6

Distinctive optimization or ML substance — 6/10. The event engine and specialized physical-modeling facilities have inspectable technical substance. Simulation remains an evaluator of chosen assumptions; the search and economic objective require additional work. 7 10 15

Real-world constraint handling — 7/10. The rail, stockyard, material, and maintenance interactions are unusually concrete. Their predictive usefulness still depends on keeping the model aligned with the operation. 4

Decision automation and labor productivity — 4/10. Batch execution can remove repetitive runs, but model building, scenario selection, and interpretation remain labor-intensive services in the published offer. Net productivity gains are not quantified. 8 9 17

Resilience under real operational complexity — 5/10. Disruptions can be modeled and hypotheses changed. The stronger test is a repeated cycle from observed failure to revised assumptions and regression validation; the case material does not demonstrate that cycle’s speed or reliability. 4 8

Product and architecture integrity

Criterion	Score
Architectural coherence	6/10
System-boundary clarity	7/10
Security seriousness	3/10
Software parsimony and ownership cost	7/10
Compatibility with programmatic and agent-assisted operations	7/10

Average: 6.0/10.

Architectural coherence — 6/10. The core engine, model logic, and optional interfaces have recognizable roles. Custom assemblies and surrounding applications can introduce project-specific dependencies that the base product does not manage away. 13 14 16

System-boundary clarity — 7/10. The documentation distinguishes engine, model, host application, and external functions. That clarity helps identify which party owns a failed assumption or integration. 15 18

Security seriousness — 3/10. Powerful extensions enlarge the impact of a model defect or compromised dependency. The public reference does not supply an equivalent account of containment and restricted production access. 7 16 18

Software parsimony and ownership cost — 7/10. Standalone deployment avoids much infrastructure overhead. The remaining expense is concentrated in specialist model maintenance, which can still dominate a long-running project. 8 13

Compatibility with programmatic and agent-assisted operations — 7/10. Text routines, batch execution, and embedding support software-driven use and revision. Turning those capabilities into a dependable decision service requires additional engineering. 11 14 17

Technical transparency

Criterion	Score
Public technical documentation	7/10
Inspectability without vendor mediation	6/10
Portability and lock-in visibility	5/10
Implementation-method transparency	6/10
Evidence density behind technical claims	5/10

Average: 5.8/10.

Public technical documentation — 7/10. The wiki exposes detailed behavior and integration mechanisms. Old versions, stale requirements, and statistical mistakes reduce confidence in using it as a current engineering reference. 6 7 13 15

Inspectability without vendor mediation — 6/10. Public interfaces and wrapper source allow meaningful examination of how the engine can be used. Customer models and the core implementation remain unavailable for independent evaluation. 14 15

Portability and lock-in visibility — 5/10. Embedding and standalone compilation improve deployment options. Model behavior still depends on the proprietary engine, and public licensing descriptions span different generations. 12 14 19

Implementation-method transparency — 6/10. Iterative development and vendor-operated analysis are described plainly. The recurring effort of data updates, model changes, and validation is not measured. 8 9

Evidence density behind technical claims — 5/10. The physical model and APIs have substantial detail. Quantified predictive performance and realized economic benefits are much thinner. 4 5 15

Vendor seriousness

Criterion	Score
Technical seriousness of public communication	6/10
Technology roadmap integrity	7/10
Conceptual sharpness	6/10
Economic accountability	4/10
Defensibility in an agentic-software world	5/10

Average: 5.6/10.

Technical seriousness of public communication — 6/10. The vendor explains actual modeling mechanisms. Leaving elementary distribution errors in a public reference undermines the care needed for uncertainty analysis. 6 7

Technology roadmap integrity — 7/10. Release history shows sustained development of simulation and integration, with a distinct fatigue product evolving separately. The continuity is stronger than the maintenance of the public documentation. 10 11 12 21

Conceptual sharpness — 6/10. Interactions and bottlenecks receive appropriate attention. The public method is less explicit about choosing the financial objective and distinguishing model fit from decision value. 5 9

Economic accountability — 4/10. Supplier involvement in iterative delivery makes model requirements discussable. Published results and licence terms do not establish accountability for net financial performance. 8 19

Defensibility in an agentic-software world — 5/10. Physical-modeling knowledge and mature engine capabilities are useful assets. Their advantage depends on reducing the specialist work required to revise and operate a valid model, a productivity result the vendor has not quantified. 8 9 11

All 25 criteria have equal weight. The total is 138/250, giving 5.52/10, rounded to 5.5/10.

Sources

Sources were accessed on November 4, 2026. Dates distinguish historical technical references from current product pages; older interface documentation describes the version or capability specified in that source.

[1] About InterDynamics

About InterDynamics. Undated.

[2] Planimate simulation software

Planimate simulation software. Undated.

[3] Supply Chain Sim

Supply Chain Sim. Undated.

[4] BHP iron ore supply chain case

BHP iron ore supply chain case. Undated.

[5] Supply chain planning

Supply chain planning. 2023-03-07.

[6] Distribution Pattern Dialog

Distribution Pattern Dialog. Last modified 2010-06-29.