SimTalk

SimTalk is the programming language you have almost certainly never written and quite possibly walked through. It exists inside exactly one product - today Siemens Tecnomatix Plant Simulation, previously eM-Plant, and before that SIMPLE++ from AESOP GmbH of Stuttgart - and its job is to describe what happens on a factory floor when the drag-and-drop objects are not enough. When a conveyor has to decide which of three buffers to feed, when a shift calendar has to interact with a breakdown distribution, when an AGV fleet has to be dispatched by a rule that no vendor dialog box anticipated, somebody writes SimTalk.

It is an odd position for a language: completely invisible from the outside, and completely unavoidable from the inside. There is no standalone compiler, no REPL, no package manager, no GitHub ecosystem, no Docker image. There is a Method object in a class library, and a text editor inside a Windows application that costs money. And yet the language has been in continuous commercial use since 1992, has had exactly one syntax revision in that time, and has just acquired an LLM front end.

History and origins

The lineage starts at the Fraunhofer Institute for Manufacturing Engineering and Automation (Fraunhofer IPA) in Stuttgart, in the research group that built factory simulators. Fraunhofer’s own publication record describes the eventual product as having been “first designed and implemented at the Fraunhofer-Institute for Manufacturing Engineering and Automation as SIMPLEmac and reimplemented based on C++ in 1992”. SIMPLE is an acronym - Simulation in Production, Logistics and Engineering - and the Macintosh version, per the commonly repeated account of the lineage, dates to 1986.

Commercialization followed the classic German institute route. A company called AIS (Angewandte Informations Systeme) was founded in Stuttgart around 1990 to take the work to market, renamed itself AESOP in 1991, and shipped the C++ rewrite as SIMPLE++. AESOP’s staff described it as a “new generation object-oriented simulation environment for modeling manufacturing, logistics and service systems that can be defined in terms of discrete events”, and, in the 1997 Winter Simulation Conference paper by David Kalasky and Gerald Levasseur of the company’s Chicago office, dated its commercial release plainly to 1992.

The language inside it was called SimTALK, capitalised that way in AESOP’s own web pages of the period. Those pages are the clearest surviving statement of what the language was for:

SIMPLE++ offers an integrated, and graphical modeling environment of a complete object-oriented built-in language. The language is called SimTALK. SimTALK is implemented as an interpreter, which makes it extremely user-friendly. Most of the modeling will usually be graphical, relying on the default behavior of the Basic Objects. However, specific rules for material or information flow, or decision rules for actions to be taken, can be implemented as necessary by a Text Editor.

That is the whole design brief, and it has never changed. SimTalk is the escape hatch from a graphical tool - not the primary interface, but the thing that makes the primary interface sufficient.

Who designed it

Nobody knows, publicly. Unusually for a language with a thirty-four-year commercial life, no individual has ever been credited with designing SimTalk. Dietmar Geuder of AESOP presented the system at the 1995 Winter Simulation Conference; Kalasky and Levasseur presented it in 1997; Siemens’ documentation refers to it only as “the proprietary programming language SimTalk”. The language is a corporate artifact in the most literal sense.

The name changes

The product went through four owners and three names while the language kept one:

At no point did anyone rename SimTalk, and at no point did anyone break existing source code badly enough to force a rewrite. For a language embedded in enterprise simulation models that outlive the factories they describe, that continuity is the whole product.

The language

A SimTalk program is not a file. It is a Method - an object in the model’s class library, sitting alongside Conveyors, Stations, Buffers, Workers and DataTables, and inheriting from a parent Method the same way any other object inherits from its class. Methods are triggered by the simulation: attached to an object’s entry control, exit control or failure control; scheduled to fire at a simulated time; run at model initialization (Init) or termination (EndSim); or called directly from another Method. This is what makes the language event-driven in a strict sense - the scheduler, not the programmer, decides when your code runs.

SimTalk 1.0

The original notation is Eiffel-flavoured, and a teaching source at Škoda Auto University describes it outright as “derived from programming language Eiffel”. The resemblance is hard to miss: declarations between is and do, the body between do and end, := for assignment, and result as the keyword that carries a function’s return value.

is
   count : integer;
do
   count := 0;
   if count >= 10 then
      print "buffer full";
   end;
end;

Every statement ends in a semicolon. Control structures are if … then … else … end, for … to/downto, while, repeat … until, loop … exitloop, and switch. The documented keyword list - which covers both notations, so it includes the SimTalk 2.0 additions var, param, div and mod - is small enough to print on a slide: and, any, array, basis, boolean, byref, continue, create, current, date, datetime, div, downto, else, elseif, end, exitloop, false, for, forget, if, integer, length, list, loop, method, mod, next, not, object, or, param, pi, print, prio, queue, real, repeat, result, return, root, rootfolder, self, speed, stack, stopuntil, string, switch, table, then, time, to, true, until, var, void, wait, waitexpired, waituntil, weight, when, while.

The type system is small, static, and interesting in one respect: alongside the ordinary integer, real, boolean, string, object and table, SimTalk has physical-quantity types - length in metres, speed in metres per second, acceleration in metres per second squared, weight in kilograms - plus time, date and datetime. These are deliberately not mutually compatible; you cannot silently add a length to a time. In a language whose entire purpose is to describe machines moving material, that is a well-judged bit of domain-specific type safety, and it long predates the fashion for units-of-measure types elsewhere.

Two more features come straight from the simulation domain rather than from general-purpose language design. wait and waituntil suspend a Method in simulated time, so a control routine can be written as a linear narrative of what a machine does rather than as a state machine over callbacks. And every model gets an Event Debugger in addition to an ordinary Method Debugger - AESOP’s 1998 specification sheet advertised the ability to view the scheduled event list, set breakpoints on events, and stop the run when a user-specified condition holds for a scheduled event. Debugging a simulation means debugging time, and the tooling has reflected that since the 1990s.

SimTalk 2.0

In Plant Simulation 12.1, around 2015-2016, Siemens shipped a second notation. The release notes are unusually candid about the motivation: SimTalk 2.0’s “features make programming methods in Plant Simulation faster, easier, and less error-prone”. The changes are a catalogue of twenty-year-old papercuts:

• Statements are line-terminated; the trailing semicolon is gone (a semicolon now separates multiple statements on one line, and an incomplete expression continues onto the next line).
• The is … do … end scaffolding is gone. Local variables are declared with var, parameters with param, and the return type after -> rather than after a colon.
• Control flow is simplified - if … else … end rather than if … then … else … end.
• Compound assignment operators +=, -= and *= were added.
• The about-equal operator became ~= instead of ==.
• The keywords div and mod replaced SimTalk 1.0’s cryptic // (integer division) and \\ (integer modulo); // now introduces a comment.
• Lists, DataTables, and the referencing of Methods and global variables all got cleaner syntax.

param arriving: object -> boolean
var waiting: integer := 0

waiting := Buffer.numMU
if waiting > 10
    print "backlog: " + to_str(waiting)
    return false
end
return true

The migration story is the part worth studying. SimTalk 1.0 was not deprecated, removed, or shimmed. Both notations remain first-class, selectable per Method with a New Syntax toggle on the ribbon, and freely mixable in a single model; clicking the toggle on an existing 1.0 Method converts its source in place, and a Shift-click on the model root converts everything at once. A decade later the current documentation still says SimTalk 1.0 “works in current and previous versions of Plant Simulation and you can continue using SimTalk 1.0 in old and new models”. Language designers with far larger user bases have handled a syntax break far worse.

Evolution and current relevance

The last decade has been about the boundary of the language rather than the language itself. Version 2201 (January 2022) added HTTP functions so a running model could talk to external servers. Recent releases added a PythonModule, which hosts Python functions inside the model and exposes them to SimTalk through .call() and .getValue(), with executePythonFile() for external scripts; the tutorial documentation notes that a system Python of 3.12.2 or newer is required. That is a meaningful admission: the interesting analysis around a simulation - optimization, statistics, machine learning - now happens in Python, and SimTalk’s job is increasingly to be the part that knows about conveyors.

And then there is the Copilot. Siemens announced an AI assistant with version 2504 in December 2025, initially for cloud-enabled users, promising SimTalk generation in a future update; version 2606, announced on 25 June 2026, delivered “LLM-based SimTalk coding support, which means it can convert natural language descriptions directly into functional SimTalk control code”, with a hosted model by default and a bring-your-own-LLM option for customers who would rather not send their plant logic anywhere.

A note on status. SimTalk is often catalogued as dormant, and for a language whose name has not appeared in a new product for three decades that is understandable - but it is not accurate. Plant Simulation is under active development, shipping several releases a year under a year-month version scheme, and SimTalk is its only native programming language. What is fair to say is that the language is frozen by design: SimTalk 2.0 in 2026 is very close to SimTalk 2.0 in 2016, and SimTalk 1.0 has been unchanged in essentials since the SIMPLE++ manuals of the 1990s. It is dormant the way a load-bearing wall is dormant.

The one genuine loss is reach. The 1998 specification sheet for SIMPLE++ V4.1 listed released platforms on Digital UNIX, HP-UX, AIX, IRIX, Solaris, SunOS, SCO Unix, Windows NT and Windows 95. Siemens today distributes Plant Simulation for Windows only. A language that once ran on seven Unixes now runs on one operating system, which is a fair summary of what happened to engineering workstations generally between 1998 and now.

Why it matters

SimTalk is a good argument for a category of language that programming-language history mostly ignores: the embedded vendor language that outlives its vendor. It has no standard, no committee, no independent implementation and no community outside a licence file, and it has nonetheless been continuously useful for thirty-four years across four corporate owners and three product names, in an industry - automotive manufacturing - where a bad model costs real money.

Three things about it are worth borrowing:

Domain types earn their keep. Making length, speed, acceleration, weight and time distinct, mutually incompatible primitive types is a small decision that prevents a specific and expensive class of error in exactly the domain the language serves. General-purpose languages have spent decades reaching for the same idea through libraries.

Simulated time belongs in the language. wait, waituntil and waitexpired let a control rule be written as a story rather than as a callback graph, and the Event Debugger treats the scheduled event list as a first-class thing to inspect and breakpoint. Coroutine-based concurrency arrived in the mainstream much later.

Compatibility is a feature you can ship. The SimTalk 1.0-to-2.0 transition - both notations valid, mixable per Method, convertible with one click, and the old one never removed - is a model of how to modernise a syntax without stranding a decade of customer code. It is not glamorous, and it is the reason models written under AESOP-era assumptions still open.

The rest of it is the ordinary fate of a good tool language: invisible, unfashionable, and running.