At its core, TransSECS is built around a very simple idea:

Every capability in the system is exposed as a named object, and every object has inputs and outputs that can be read or written.

That’s it.

Once you know the name of something, you can interact with it.

This applies consistently across:

• SECS/GEM messages
• Equipment state
• Host commands
• Data collection
• Scripts
• External interfaces (REST, MQTT, AMQP)

This consistency is what makes TransSECS both easy to use *and* extremely powerful.

Instead of thinking in terms of code, think of the system like this:

• The system is a hierarchy of named components
• Each component has:
  • Inputs (things you can set)
  • Outputs (things you can read)
• Components can also take actions when triggered

In MIStudio and TransSECS terms, these are:

• Inports → inputs you can write to
• Outports → outputs you can read from

Everything in TransSECS follows this pattern.

Every input or output can be accessed using a simple path:

/ToolName/ComponentName>FieldName

For example:

/E300Host/PRJobCreateEnh>PRJOBID

This means:

• Tool: `E300Host`
• Component: `PRJobCreateEnh`
• Field: `PRJOBID`

If you can name it, you can use it.

Because everything is addressable by name, TransSECS can accept simple data (like JSON) and automatically apply it to the system.

Example:

{
"/E300Host/PRJobCreateEnh>DATAID": "1",
"/E300Host/PRJobCreateEnh>PRJOBID": "TestJob-JUnit5",
"/E300Host/PRJobCreateEnh>MF": "14",
"/E300Host/PRJobCreateEnh>MIDs": {"values": ["Wafer01","Wafer02"],"type": 20 },
"/E300Host/PRJobCreateEnh>PRRECIPEMETHOD": "2",
"/E300Host/PRJobCreateEnh>RCPSPEC": "TestRecipe",
"/E300Host/PRJobCreateEnh>PRPROCESSSTART": "true",
"/E300Host/PRJobCreateEnh>sendMessage": ""
}

What happens:

1. Each entry sets a value inside the system
2. The final `“sendMessage”` triggers the action
3. No custom parsing code is required
4. No special API per message type

This same payload could come from:

• REST API
• MQTT
• AMQP
• Internal scripts

There is no separate API for:

• Creating jobs
• Sending commands
• Updating state
• Triggering actions

It’s all the same mechanism:

• Write values → trigger action

This dramatically reduces complexity.

Users can:

• Configure complex behavior
• Build integrations
• Drive equipment

…using:

• JSON
• Scripts
• Configuration

Instead of writing custom Java code.

The exact same structure works for:

• UI interactions
• Scripts
• Programmatic Integration
• REST calls
• MQTT messages
• AMQP messages

No translation layer needed.

New capabilities can be added without breaking anything:

• New components appear in the hierarchy
• They automatically become addressable
• They automatically work with existing tools

This is why ErgoTech can add features quickly.

Because everything is:

• Named
• Structured
• Discoverable
• Writable via data

It becomes ideal for:

• Automation workflows
• Low-code / no-code systems
• AI-driven control (LLMs, agents)

Traditional approach:

• Custom API per function
• Hard-coded logic
• Tight coupling
• Difficult to extend

TransSECS approach:

• Unified addressing model
• Data-driven control
• Loose coupling
• Easy to extend

With this architecture, you get:

• Faster integration with tools and systems
• Reduced engineering effort
• Greater flexibility as requirements change
• The ability to automate without deep programming
• A system that grows with your needs

TransSECS is built on a simple but powerful principle:

If you can name it, you can control it.

This enables:

• Simplicity for users
• Power for advanced applications
• Speed for development
• Flexibility for the future

This same architectural foundation is what powers MIStudio, where it expands into:

• Visual flows
• Distributed systems
• Data orchestration
• AI-driven automation

(Think: *Node-RED… multiplied by several orders of magnitude.*)