LCN Wafer Inspection

Appearance

Part 1 — Why extensibility matters in machine software ​

In industrial machine software, extensibility is usually a product-line problem, not a luxury feature. A machine platform rarely stays as one fixed system. Over time, the same software family is expected to support different hardware combinations, different customer options, and new capabilities that were not present in version one. That fits the roadmap’s emphasis on industrial software architecture including plugin / modular architecture, device manager patterns, configuration architecture, and separation of UI, workflow, and device logic.

A few very normal real-world examples:

  • One machine variant has one camera, another has two cameras with different synchronization behavior.
  • One customer requires an extra inspection step after alignment, while another skips it.
  • One machine family uses a robotic handler, another uses a gantry transport.
  • Service tools and maintenance screens differ depending on the installed hardware set.

If the architecture does not anticipate variation, teams usually fall into one of these patterns:

  • if (MachineType == A) ... else if (MachineType == B) ...
  • duplicated workflows per customer
  • device-specific logic leaking into orchestration code
  • UI screens branching on every product variant
  • hard-coded assumptions that “this machine always has device X”

That works briefly, then collapses. The core system becomes full of product exceptions. Changes become risky because every variant is entangled with every other variant. Upgrades become fragile because old assumptions are buried everywhere.

In machine software, that is especially dangerous because variation is not just cosmetic. It can affect:

  • workflow legality
  • startup sequencing
  • safety checks
  • device dependencies
  • operator-visible capabilities
  • recovery behavior after faults

So extensibility is not about making the code look elegant. It is about keeping a machine platform evolvable without destabilizing shared behavior.

Part 2 — What a plugin / extension really is ​

A plugin is not just “a DLL loaded dynamically.” In a serious machine system, a plugin is a separately implemented capability that connects to the system through defined contracts.

An extension point is a place where the platform intentionally allows variation.

That variation can appear in several forms:

  • optional modules
  • family-specific device implementations
  • workflow step providers
  • customer/site policies
  • feature-specific UI panels
  • alternative algorithms or handlers

So extensibility is broader than classic plugins. A plugin is only one packaging form. The deeper architectural idea is this:

the core system defines where change is allowed, and how that change is allowed.

That is the difference between:

Changing core code

  • modify orchestration
  • add more conditionals
  • patch shared state handling
  • let variant logic spread inward

and

Adding extension behavior through stable contracts

  • implement a device provider interface
  • register an optional workflow step
  • contribute a feature module with declared capabilities
  • add a policy component used by the core through a contract

The first model makes every variation a core change. The second model treats variation as a controlled external contribution.

That distinction is critical in machine software because the core platform usually owns things that must remain predictable: lifecycle, workflow integrity, state consistency, alarms, and safety-related rules.

Part 3 — Stable core vs variable edges ​

Good extensibility architecture keeps the core stable and pushes variability to the edges.

The core should own:

  • shared orchestration
  • common machine/workflow state model
  • lifecycle and initialization rules
  • safety and interlock enforcement boundaries
  • common abstractions and contracts
  • common error handling and diagnostics patterns

The variable edges often include:

  • device-specific implementations
  • optional inspection logic
  • machine-family-specific modules
  • customer-specific integrations
  • optional service tooling
  • capability-specific UI contributions

ASCII component diagram ​

text
+--------------------------------------------------+
|                  Core Platform                   |
|--------------------------------------------------|
|  - Common Contracts                             |
|  - Workflow / State Core                        |
|  - Safety / Lifecycle Rules                     |
|  - Extension Point Manager                      |
+-------------------------+------------------------+
                          |
          +---------------+---------------+
          |               |               |
          v               v               v
+----------------+ +----------------+ +----------------+
|    Plugin A    | |    Plugin B    | |    Plugin C    |
|----------------| |----------------| |----------------|
| Device Adapter | | Workflow Step  | | UI / Service   |
| or Variant     | | or Inspection  | | Module         |
| Capability     | | Hook           | |                |
+----------------+ +----------------+ +----------------+

What this diagram means ​

The important idea is not “plugins exist.” The important idea is dependency direction and ownership.

The core owns the rules. Plugins contribute behavior only through approved seams.

That is why letting plugins mutate core invariants is dangerous. If a plugin can directly rewrite machine state, bypass workflow sequencing, or ignore lifecycle transitions, then the architecture is no longer extensible. It is just porous.

A strong architecture says:

  • plugins may contribute
  • plugins may declare capabilities
  • plugins may implement contracts
  • plugins may react to events
  • plugins may participate in workflows

But plugins may not silently redefine core truths such as:

  • what “machine ready” means
  • what startup validity requires
  • what safety gating must pass before motion
  • how workflow state transitions are enforced

That boundary is what keeps extensibility from becoming chaos.

Part 4 — Extensibility points in real machine systems ​

Now let’s make this concrete.

1. Device providers / adapters ​

What varies

  • camera vendor
  • motion controller family
  • IO implementation
  • robot integration
  • different hardware topologies across machine models

Why extensibility helps You want the platform to talk in terms of machine capabilities, not vendor SDK details. A new camera should not require rewriting orchestration, UI, and workflow layers.

What should remain fixed in the core

  • device lifecycle expectations
  • common health model
  • command/result semantics
  • alarm/error propagation rules
  • ownership rules for shared resources

A plugin here might implement ICameraProvider or IAxisControllerFactory, but it should still fit into the same startup, health, and diagnostics model as every other device.

2. Workflow step providers ​

What varies

  • optional inspection steps
  • family-specific handling steps
  • extra calibration step for one machine type
  • customer-required verification step

Why extensibility helps You can extend a standard workflow without forking the entire workflow engine or copying the whole process definition.

What should remain fixed in the core

  • workflow execution model
  • state transitions
  • pause/resume/abort semantics
  • timeout and fault handling policies
  • execution context rules

The extension should provide a step implementation, not take control of the entire process engine.

3. Inspection algorithm hooks ​

What varies

  • optional defect filters
  • product-family-specific post-processing
  • measurement strategy by installed optics package
  • customer-specific result rules

Why extensibility helps Algorithmic variation is common, especially when product lines evolve. The core can standardize acquisition, result flow, and error handling while allowing specialized processing modules.

What should remain fixed in the core

  • pipeline lifecycle
  • data ownership
  • result publication contracts
  • timing and cancellation rules
  • traceability boundaries

4. Machine feature modules ​

What varies

  • extra camera head
  • autofocus subsystem
  • barcode reader
  • special loader/unloader
  • optional metrology module

Why extensibility helps Installed hardware should map to installed capabilities, not to hidden code branches scattered through the system.

What should remain fixed in the core

  • feature registration model
  • machine state integration
  • startup validation
  • operator-facing enable/disable rules
  • diagnostics visibility

5. Service / diagnostic tools ​

What varies

  • vendor-specific diagnostics
  • axis tuning screens
  • maintenance panels
  • advanced service utilities for optional subsystems

Why extensibility helps Service engineers need tools only relevant to installed hardware. You do not want the main HMI hard-coded with every possible service screen for every variant.

What should remain fixed in the core

  • authentication/authorization boundary if present
  • audit/logging behavior
  • lifecycle rules
  • safe access conditions
  • consistent shell/navigation model

6. Customer/site-specific policy modules ​

What varies

  • naming conventions
  • external system integration rules
  • product acceptance logic
  • result routing rules
  • site workflow policy

Why extensibility helps Customer differences are often real, but they should not infect the shared product core.

What should remain fixed in the core

  • platform domain model
  • state model
  • workflow engine semantics
  • safety and machine lifecycle invariants

7. Optional UI panels tied to installed capabilities ​

What varies

  • device dashboards
  • calibration panels
  • maintenance pages
  • optional inspection result viewers

Why extensibility helps UI should reflect what the machine actually has, not what the superset product family might support.

What should remain fixed in the core

  • navigation shell
  • permission model
  • UI lifecycle
  • common status model
  • interaction contracts with application services

Part 5 — Designing safe extension contracts ​

This is where many systems either become robust or become fragile.

Extension contracts must be:

  • explicit
  • stable
  • narrow in scope
  • version-aware
  • aligned with actual ownership boundaries

A good extension contract might include:

  • interfaces
  • message/event contracts
  • lifecycle hooks
  • capability declarations
  • metadata
  • configuration schemas
  • validation hooks

The core rule ​

Expose only what the extension truly needs.

Bad extensibility design often comes from overexposure. Teams say, “Let’s make it flexible,” then hand the plugin a giant internal service locator, direct machine state objects, mutable workflow internals, or unrestricted event streams.

That creates two failures:

  1. coupling

    • plugins now depend on internals that the core wants to evolve

  2. power without boundaries

    • plugins can do things the architecture cannot safely reason about

Good example ​

A device plugin gets:

  • IDeviceProvider
  • lifecycle callbacks
  • capability registration API
  • logger
  • validated configuration
  • specific service contracts it needs

It does not get:

  • unrestricted access to global machine state
  • direct mutation of workflow internals
  • arbitrary control over unrelated devices

Another good example ​

An optional workflow step implements a defined contract like:

text
IWorkflowStep
  - Metadata
  - Preconditions
  - ExecuteAsync(context, cancellationToken)
  - Validate(configuration)

It does not get a way to arbitrarily rearrange the workflow engine itself.

That difference matters. It preserves the core’s right to remain the workflow owner.

Part 6 — Loading, discovery, and capability registration ​

Loading extensions is not just “find DLL and call methods.”

In industrial systems, extension loading is part of machine boot validity.

A plugin may affect whether the machine is correctly understood at startup. So the platform usually needs a disciplined startup flow:

ASCII interaction diagram ​

text
Startup
   |
   v
Discover Plugins
   |
   v
Validate Compatibility
   |
   v
Validate Configuration
   |
   v
Resolve Dependencies
   |
   v
Register Capabilities
   |
   v
Enable Features
   |
   v
Machine Ready / Degraded / Blocked

What this diagram means ​

The system typically needs to perform several checks before enabling a feature:

  • Is the plugin compatible with this software version?
  • Is it valid for this machine family?
  • Are required peer capabilities present?
  • Is its configuration complete and valid?
  • Is required hardware actually present and reachable?
  • Does it declare capabilities that conflict with another plugin?
  • Can it enter lifecycle readiness successfully?

Only after that should the system expose the feature to operators or workflows.

Capability registration ​

A mature design often uses capability-based registration instead of hard-coded type checks.

Instead of:

text
if (machineType == TwinCameraModel)

the core asks:

  • is DualCameraInspection capability present?
  • is AutoFocus capability registered?
  • is WaferHandler capability available and ready?

That is a much healthier model because it ties behavior to declared installed capability, not brittle product-name branching.

Why startup validation matters ​

In machine software, a plugin that “loads” but is not actually valid is dangerous.

Examples:

  • plugin exists, but machine does not have that hardware installed
  • hardware exists, but plugin config references the wrong channel mapping
  • feature is registered, but required calibration is missing
  • UI panel appears, but service cannot execute safely
  • workflow step is available, but dependency capability is absent

A strong platform catches these at startup and sets the machine into a clear state:

  • ready
  • degraded but usable
  • blocked until issue resolved

Not “half-loaded and surprising.”

Part 7 — Real-world failure scenarios ​

1. Plugin depends on internal core behavior that later changes ​

What it looks like in production A core refactor changes internal startup order or state timing. Plugin still compiles, but now fails intermittently or behaves incorrectly.

Why it happens The plugin was built against internals, not contracts.

How experienced engineers prevent it

  • narrow public extension APIs
  • keep internal services internal
  • version extension contracts explicitly
  • use compatibility checks during load
  • test core against representative extension suites

2. Extension bypasses safety or state rules ​

What it looks like in production A service module issues a device command directly without going through required readiness checks or workflow gating.

Why it happens The plugin had too much power or the architecture had an unofficial backdoor.

How experienced engineers prevent or diagnose it

  • centralize guarded command paths
  • separate “request action” from “execute action”
  • make safety/lifecycle checks unavoidable in core services
  • log command origin and decision path
  • block direct device access except in explicitly controlled maintenance boundaries

3. Multiple plugins overlap responsibilities and conflict ​

What it looks like in production Two plugins both believe they own result post-processing, or both try to register UI for the same feature zone, or both handle the same device category.

Why it happens Extension contracts are ambiguous. Ownership is not part of the registration model.

How experienced engineers prevent it

  • define ownership rules in contracts
  • use capability namespaces or slots
  • fail startup on ambiguous registration
  • require explicit precedence rules where composition is allowed

4. Machine variant logic leaks into core anyway ​

What it looks like in production Even with “plugins,” the core still contains dozens of if machine family checks.

Why it happens The architecture declared plugins, but did not identify real variability points. So teams kept patching the core.

How experienced engineers prevent it

  • review where product-specific branching appears
  • convert repeated conditionals into capability queries or strategy contracts
  • treat product-line branching inside core as architectural debt

5. Optional module is installed physically but capability registration is wrong ​

What it looks like in production The machine physically has the subsystem, but the feature is invisible, disabled, or partially active.

Why it happens Misconfiguration, version mismatch, or incomplete plugin registration.

How experienced engineers prevent or diagnose it

  • capability manifest visible in diagnostics
  • startup reports showing detected vs configured vs enabled features
  • explicit readiness state per capability
  • service screens that show why a feature is blocked

6. Plugin loads successfully but is incompatible with current machine/software version ​

What it looks like in production Machine starts, but crashes when the feature is first used, or enters a degraded state later during operation.

Why it happens Loading was treated as success, but compatibility semantics were weak.

How experienced engineers prevent it

  • contract versioning
  • minimum/maximum supported platform version declaration
  • machine-family compatibility metadata
  • startup-time validation, not lazy discovery during live operation

Part 8 — Software design implications ​

Extensibility must be intentional.

If you do not deliberately define where variation belongs, the system will create accidental extensibility through conditionals, hidden assumptions, and copy-paste. That is the worst form, because it gives all the pain of variation with none of the architectural control.

A strong design usually includes:

  • stable contracts
  • capability-based design
  • explicit extension boundaries
  • startup validation
  • protected core invariants
  • narrow plugin permissions
  • compatibility/version rules
  • ownership clarity for registered contributions

Bad approach ​

  • hard-coded variant branching everywhere
  • plugins reaching into core internals
  • direct device access from arbitrary extensions
  • customer customization by code copy
  • extension success defined as “assembly loaded”
  • optional features enabled without dependency validation

Good approach ​

  • define explicit variability points
  • keep the core responsible for orchestration/state/lifecycle/safety boundaries
  • let plugins implement narrowly scoped contracts
  • register capabilities, not product-name assumptions
  • validate compatibility, dependency, and readiness at startup
  • fail clearly when the extension model is violated

ASCII dependency diagram ​

text
         +----------------------+
         |   Contract Package   |
         |----------------------|
         | Interfaces           |
         | Messages             |
         | Capability Metadata  |
         | Lifecycle Contracts  |
         +----------+-----------+
                    ^ 
                    |
        +-----------+-----------+
        |                       |
        |                       |
+---------------+       +---------------+
|  Core System  |       |    Plugins    |
|---------------|       |---------------|
| Workflow Core |       | Device Mods   |
| State Core    |       | UI Mods       |
| Loader        |       | Feature Mods  |
| Validator     |       | Policies      |
+---------------+       +---------------+

Core depends on contracts
Plugins depend on contracts
Core does NOT depend on plugin implementations directly

Why this dependency shape matters ​

This is the architectural center of gravity.

The contract package becomes the stable seam. The core can discover plugins, validate them, and invoke them through contracts. Plugins can evolve independently within that boundary. The core does not directly reference concrete plugin implementations.

That gives you both extensibility and control.

Part 9 — Interview / real-world talking points ​

A clear way to explain plugin and extensibility architecture is this:

Industrial machine software often supports a family of related machines rather than one fixed product. The core platform should own shared orchestration, state, lifecycle, and safety-related rules, while machine-specific or optional behavior is added at defined extension points. The goal is to keep the core stable and push variability to controlled edges.

A strong explanation of why stable core with variable edges matters:

Because machine software changes in two directions at once. Shared platform behavior must remain reliable across long-lived products, while hardware options, customer workflows, and subsystem combinations continue to evolve. If the architecture does not separate those forces, the core becomes a tangle of product-specific branching and upgrades become fragile.

Common mistakes engineers make:

  • they confuse “dynamic loading” with good extensibility
  • they expose too much of the core to plugins
  • they let plugins bypass lifecycle or safety boundaries
  • they leave ownership ambiguous between overlapping extensions
  • they keep product branching in the core even after adding a plugin model
  • they skip startup validation and discover incompatibility only during live operation

What strong engineers understand:

  • extensibility is about controlled variation, not unrestricted freedom
  • the hardest part is identifying the right variation points
  • contracts must be stable, narrow, and version-aware
  • capability registration is better than product-name branching
  • the core must protect its invariants
  • plugin loading is part of system validity, not just implementation detail
  • long-term product-line evolution matters more than short-term convenience

One good interview close is:

In machine software, the right extensibility model is not one where plugins can do anything. It is one where the platform stays trustworthy while optional behavior can be added safely. The core owns the invariants. Extensions contribute through contracts.

That is usually the difference between a platform that survives five years of product evolution and one that collapses under variant-specific hacks.

This topic aligns directly with the roadmap’s architectural focus on plugin / modular architecture within industrial software systems.

Docs-first project memory for AI-assisted implementation.

LCN Wafer Inspection Prototype