LCN Wafer Inspection

Appearance

UI/HMI ​

6.1 ​

You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).

You have real production experience, including:

  • designing operator-facing systems tightly integrated with machine workflows
  • separating UI concerns from machine control, workflow, and device layers
  • handling long-running UI applications that must remain stable for days/weeks
  • debugging systems where UI design caused incorrect machine operation or operator confusion

I am a senior .NET engineer transitioning into this domain.

I want to deeply understand how HMI systems are architected in industrial machines.

=== TOPIC === HMI System Architecture

=== GOAL ===

Help me understand how the operator interface fits into the overall machine system architecture.

Focus on:

  • UI as part of the machine system (not just frontend)
  • separation of UI, workflow, and machine control
  • data flow between subsystems
  • architectural boundaries and responsibilities

=== ALIGNMENT WITH SOURCE OF TRUTH ===

This topic corresponds to:

"HMI system architecture"

Do NOT introduce unrelated topics.

=== STYLE & DEPTH ===

Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.

Focus on:

  • system-level architecture
  • real-world constraints
  • integration with machine behavior

Avoid:

  • WPF control-level details
  • generic UI design theory
  • shallow layering explanations

=== DIAGRAM STYLE ===

Use UML-style ASCII diagrams:

  • Layer diagrams → UI vs workflow vs machine vs devices
  • Data flow diagrams → state and command flow
  • Component diagrams → system structure

Rules:

  • ASCII only
  • simple and readable
  • clearly explain each diagram

=== SCOPE CONTROL ===

Stay within:

  • HMI system architecture
  • interaction with machine system

Do NOT deep dive into:

  • UI rendering details
  • specific screens (later topics)
  • detailed concurrency (Topic 6.2)

=== STRUCTURE ===

=== PART 1 — WHY HMI IS PART OF THE MACHINE, NOT JUST UI ===

Explain:

  • HMI is not just visualization layer
  • it participates in:
    • machine control
    • workflow execution
    • operator decision making

Explain:

  • UI mistakes can cause:
    • incorrect commands
    • unsafe actions
    • production errors

Use examples:

  • wrong button enabled → operator triggers motion at wrong time
  • UI shows stale state → operator acts on incorrect info

=== PART 2 — CORE ARCHITECTURE LAYERS ===

Explain typical architecture:

[UI Layer] ↓ [Application / Workflow Layer] ↓ [Machine Control Layer] ↓ [Device Layer]

Explain responsibility of each:

  • UI → display + input
  • workflow → logic + sequencing
  • machine control → commands + state
  • device → hardware interaction

Include ASCII diagram

=== PART 3 — DATA FLOW: STATE VS COMMAND ===

Explain:

Two key flows:

  1. Machine → UI (state flow)
  2. UI → Machine (command flow)

Explain:

  • state must be:
    • accurate
    • timely
  • commands must be:
    • validated
    • controlled

Include ASCII flow diagram

=== PART 4 — WHY UI MUST BE DECOUPLED ===

Explain:

  • UI should not:
    • directly call devices
    • control timing-sensitive operations
    • contain business/workflow logic

Explain risks:

  • tight coupling causes:
    • fragile system
    • hard debugging
    • unsafe behavior

=== PART 5 — LONG-RUNNING UI SYSTEM CONSTRAINTS ===

Explain:

  • machine UI runs:
    • continuously (hours/days/weeks)
  • must handle:
    • memory stability
    • thread safety
    • reconnect scenarios
    • UI responsiveness under load

Explain:

  • difference from typical business apps

=== PART 6 — MULTIPLE UI MODES ===

Explain:

  • operator mode
  • manual/service mode
  • engineering mode

Explain:

  • why UI behavior changes per mode
  • why architecture must support mode switching safely

=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===

Explain:

  • UI directly controls device → race condition
  • UI shows cached state → wrong operator decision
  • UI freeze blocks critical feedback
  • UI triggers command without validation
  • UI logic duplicated across screens → inconsistency

For each:

  • what it looks like
  • why it happens
  • how engineers fix it

=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===

Explain:

  • HMI must be:
    • decoupled
    • state-driven
    • observable

Important patterns:

  • MVVM (adapted for machine systems)
  • state models
  • command models
  • event-driven updates

Explain good vs bad:

  • bad: UI directly talks to hardware
  • good: UI talks to application layer only

=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===

Give:

  • how to explain HMI architecture clearly
  • why UI must not control machine directly
  • common mistakes engineers make
  • what strong engineers understand about UI boundaries

=== OUTPUT ===

  • structured explanation
  • real-world HMI architecture insights
  • ASCII UML-style diagrams
  • practical language suitable for real systems and interviews

6.2 ​

You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).

You have real production experience, including:

  • designing systems where UI reflects real machine state under concurrency and latency
  • handling event-driven updates from motion, sensors, vision, alarms, and workflows
  • preventing stale, inconsistent, or misleading UI state
  • debugging issues where UI and machine state diverged, causing operator errors

I am a senior .NET engineer transitioning into this domain.

I want to deeply understand how machine state is represented and synchronized with the UI in real time.

=== TOPIC === Machine State & Real-Time UI Synchronization

=== GOAL ===

Help me understand how industrial systems keep the UI consistent with real machine state under concurrency, latency, and failures.

Focus on:

  • state modeling
  • real-time updates (events vs polling)
  • UI thread vs background threads
  • consistency, staleness, and correctness
  • practical synchronization patterns

=== ALIGNMENT WITH SOURCE OF TRUTH ===

This topic corresponds to:

"Machine state & real-time UI synchronization"

Do NOT introduce unrelated topics.

=== STYLE & DEPTH ===

Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.

Focus on:

  • correctness under concurrency
  • system-level state flow
  • real-world failure modes

Avoid:

  • basic WPF binding tutorials
  • shallow “use INotifyPropertyChanged” answers
  • deep OS/threading theory without context

=== DIAGRAM STYLE ===

Use UML-style ASCII diagrams:

  • State flow diagrams → machine → app → UI
  • Event flow diagrams → producers → subscribers
  • Consistency diagrams → expected vs stale UI

Rules:

  • ASCII only
  • simple and readable
  • clearly explain each diagram

=== SCOPE CONTROL ===

Stay within:

  • state representation
  • real-time updates
  • synchronization patterns

Do NOT deep dive into:

  • command handling (Topic 6.3)
  • UI layout/screens (Topic 6.5)
  • low-level threading internals

=== STRUCTURE ===

=== PART 1 — WHAT “MACHINE STATE” REALLY IS ===

Explain:

  • machine state is a composite view of:
    • motion (positions, velocities, status)
    • device states (connected, ready, faulted)
    • workflow state (idle, running, paused, step X)
    • alarms/faults
    • vision status/results
    • IO/sensor signals
    • recipe/config context

Explain:

  • state is not a single variable
  • it is a continuously changing system snapshot

Use example:

  • “Machine is Running” → actually includes many sub-states

=== PART 2 — STATE FLOW ARCHITECTURE ===

Explain the canonical flow:

[Devices / Controllers] ↓ (events / polling) [Machine Control Layer] ↓ (normalized state) [Application / State Model] ↓ (observable state) [UI ViewModels] ↓ [UI Rendering]

Explain:

  • normalization and aggregation of state
  • why UI must NOT read directly from devices

Include ASCII diagram

=== PART 3 — EVENT-DRIVEN VS POLLING ===

Explain:

Event-driven:

  • push updates when something changes
  • lower latency, more reactive

Polling:

  • periodic reads
  • simpler but may be stale or wasteful

Explain hybrid approach:

  • event-driven for critical signals
  • polling for slow-changing or legacy systems

Discuss trade-offs:

  • missed events vs stale polling windows

=== PART 4 — UI THREAD VS BACKGROUND THREADS ===

Explain:

  • device updates and processing happen on background threads
  • UI must update on UI thread

Explain risks:

  • cross-thread access exceptions
  • blocking UI thread
  • flooding UI with updates

Explain patterns:

  • dispatcher/synchronization context
  • batching/throttling updates
  • coalescing frequent changes

Include ASCII flow: Background Events → State Model → UI Dispatcher → ViewModel → UI

=== PART 5 — CONSISTENCY & STALENESS ===

Explain:

  • UI must answer: “Is this state accurate NOW?”

Problems:

  • stale values
  • partial updates
  • out-of-order events
  • race conditions between updates

Explain strategies:

  • timestamps/versioning
  • immutable snapshots
  • atomic state updates
  • “last-known-good” vs “current-unknown” indicators

Include ASCII comparison: Expected timeline vs delayed UI timeline

=== PART 6 — HIGH-FREQUENCY DATA HANDLING ===

Explain:

  • some signals update very fast (e.g., positions, sensors, vision streams)
  • UI cannot render every update

Strategies:

  • sampling (e.g., 10–20 Hz for display)
  • downscaling/aggregation
  • separating “control data” vs “display data”

Explain:

  • difference between control correctness and display fidelity

=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===

Explain:

  • UI shows “Idle” but machine is still moving
  • button enabled because state update lagged
  • alarm cleared in backend but still visible on UI
  • UI freezes due to update storm
  • position displayed jumps backward (out-of-order events)
  • multiple sources overwrite state inconsistently

For each:

  • what it looks like
  • why it happens
  • how engineers fix it

=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===

Explain:

  • need for a central state model (single source of truth)
  • importance of:
    • event normalization
    • state aggregation
    • immutable snapshots or controlled mutation
    • UI-safe update pipeline
    • throttling/coalescing mechanisms
    • diagnostics for state latency

Explain good vs bad:

  • bad: UI reads devices directly, multiple state sources, uncontrolled updates
  • good: centralized state service, event-driven updates, controlled UI synchronization

=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===

Give:

  • how to explain real-time UI synchronization clearly
  • why “latest value” is not always correct value
  • common mistakes software engineers make
  • what strong engineers understand about state flow, consistency, and concurrency

=== OUTPUT ===

  • structured explanation
  • real-world state synchronization insights
  • ASCII UML-style diagrams
  • practical language suitable for real systems and interviews

6.3 ​

You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).

You have real production experience, including:

  • designing safe operator command flows for industrial HMIs
  • preventing unsafe commands from reaching machine control layers
  • handling start / stop / pause / resume / abort behavior from the UI
  • debugging systems where poor UI command handling caused unsafe motion, inconsistent workflow state, or operator confusion

I am a senior .NET engineer transitioning into this domain.

I want to deeply understand how HMI command handling is designed safely in industrial machine software.

=== TOPIC === Command Handling & Safe Control

=== GOAL ===

Help me understand how operator commands are accepted, validated, routed, executed, and rejected safely.

Focus on:

  • UI command model
  • command enablement / disablement
  • safe command gating
  • state/mode/interlock validation
  • preventing UI from directly controlling hardware

=== ALIGNMENT WITH SOURCE OF TRUTH ===

This topic corresponds to:

"Command handling & safe control"

Do NOT introduce unrelated topics.

=== STYLE & DEPTH ===

Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.

Focus on:

  • real-world command safety
  • operator interaction
  • system-level control boundaries

Avoid:

  • basic ICommand tutorials
  • shallow button-click examples
  • generic UI command theory without machine context

=== DIAGRAM STYLE ===

Use UML-style ASCII diagrams:

  • Command flow diagrams → UI to machine control
  • Validation diagrams → state/mode/interlock checks
  • Sequence diagrams → accepted vs rejected command flow

Rules:

  • ASCII only
  • simple and readable
  • clearly explain each diagram

=== SCOPE CONTROL ===

Stay within:

  • HMI command handling
  • safe operator control
  • command validation and routing

Do NOT deep dive into:

  • alarm design (Topic 6.4)
  • detailed workflow internals
  • low-level hardware control

=== STRUCTURE ===

=== PART 1 — WHY UI COMMANDS ARE SAFETY-CRITICAL ===

Explain:

  • HMI commands can cause physical machine behavior
  • a button click is not just a UI event; it may initiate:
    • motion
    • workflow execution
    • device activation
    • recipe application
    • fault reset

Explain:

  • why UI command handling must be treated as a controlled safety boundary

Use examples:

  • Start command when machine is not ready
  • Manual move command while auto workflow is running
  • Reset alarm without resolving physical cause

=== PART 2 — COMMAND INTENT VS COMMAND EXECUTION ===

Explain clearly:

  • UI expresses operator intent
  • application layer decides whether intent is allowed
  • machine control layer executes validated command

Explain:

  • why UI should never directly execute hardware actions

Include ASCII diagram: Operator → UI Command Intent → Command Validator → Machine Controller → Device Layer

=== PART 3 — COMMAND ENABLEMENT / DISABLEMENT ===

Explain:

  • buttons should reflect whether actions are currently allowed
  • enablement depends on:
    • machine state
    • operating mode
    • user role
    • interlocks
    • workflow status
    • device readiness

Explain:

  • why UI enablement is only guidance, not final safety protection
  • backend validation must still enforce rules

=== PART 4 — SAFE COMMAND GATING ===

Explain command validation pipeline:

  1. Is user authorized?
  2. Is command valid in current mode?
  3. Is command valid in current machine state?
  4. Are interlocks/permissives satisfied?
  5. Are required devices ready?
  6. Is workflow in a valid transition point?
  7. Should command be accepted, rejected, queued, or require confirmation?

Include ASCII validation flow diagram

=== PART 5 — HANDLING START / STOP / PAUSE / RESUME / ABORT ===

Explain practical command semantics:

  • Start: begin controlled workflow if ready
  • Stop: controlled stop at safe boundary
  • Pause: suspend workflow safely
  • Resume: continue only if state/context still valid
  • Abort: interrupt operation more aggressively, leaving system in known recovery state

Explain:

  • why these commands are not interchangeable
  • why stop/abort behavior must be explicit

=== PART 6 — MANUAL CONTROL COMMANDS ===

Explain:

  • manual control commands are powerful and risky
  • examples:
    • jog axis
    • turn vacuum on/off
    • trigger camera
    • open/close clamp

Explain:

  • manual commands must be gated by:
    • mode
    • role
    • safety state
    • machine condition
    • resource ownership

Explain:

  • why manual mode must not become “bypass all rules” mode

=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===

Explain:

  • UI button enabled based on stale state
  • UI disables command but backend still accepts it from another path
  • operator double-click causes duplicate command
  • manual command conflicts with running workflow
  • reset command clears UI alarm but subsystem is still unsafe
  • command accepted while device is not ready
  • stop command behaves differently depending on hidden state

For each:

  • what it looks like in production
  • why it happens
  • how experienced engineers diagnose and handle it

=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===

Explain:

  • command handling must be centralized and traceable
  • importance of:
    • command objects / requests
    • command validation service
    • central command gateway
    • backend enforcement independent of UI enablement
    • idempotency / duplicate prevention where needed
    • audit trail for operator actions
    • explicit rejection reasons

Explain good vs bad approaches:

  • bad: button click directly calls device API or workflow method
  • good: UI sends command intent; application validates; machine controller executes; result is reported back

Include ASCII component diagram: View/ViewModel ↓ CommandIntent Application Command Gateway ↓ Validate Machine Controller / Workflow ↓ Execute CommandResult → UI / Audit / Logs

=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===

Give:

  • how to explain safe HMI command handling clearly
  • why UI enablement is not enough
  • common mistakes software engineers make when entering industrial UI
  • what strong engineers understand about command intent, validation, safety gating, and traceability

=== OUTPUT ===

  • structured explanation
  • real-world command handling insights
  • ASCII UML-style diagrams
  • practical language suitable for real systems and interviews

6.4 ​

You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).

You have real production experience, including:

  • designing alarm systems that clearly communicate faults to operators
  • structuring alarm severity, lifecycle, and acknowledgement flows
  • integrating alarms with machine state, workflow, and UI
  • debugging systems where poor alarm design caused operator confusion, slow recovery, or unsafe behavior

I am a senior .NET engineer transitioning into this domain.

I want to deeply understand how alarm systems and operator guidance are designed in industrial machines.

=== TOPIC === Alarm Systems & Operator Guidance

=== GOAL ===

Help me understand how industrial systems detect, represent, and communicate faults to operators, and guide them toward correct actions.

Focus on:

  • alarm classification and severity
  • alarm lifecycle (raise → active → acknowledge → clear)
  • operator guidance and messaging
  • integration with machine state and workflow

=== ALIGNMENT WITH SOURCE OF TRUTH ===

This topic corresponds to:

"Alarm systems & operator guidance"

Do NOT introduce unrelated topics.

=== STYLE & DEPTH ===

Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.

Focus on:

  • real-world operator behavior
  • clarity under stress
  • system-level fault handling

Avoid:

  • generic logging discussions
  • shallow “show message box” explanations
  • deep safety certification details

=== DIAGRAM STYLE ===

Use UML-style ASCII diagrams:

  • Lifecycle diagrams → alarm states and transitions
  • Flow diagrams → fault detection → alarm → operator action → recovery
  • Component diagrams → detection sources → alarm service → UI

Rules:

  • ASCII only
  • simple and readable
  • clearly explain each diagram

=== SCOPE CONTROL ===

Stay within:

  • alarm systems
  • operator guidance
  • alarm lifecycle and interaction

Do NOT deep dive into:

  • command handling (Topic 6.3)
  • low-level device fault detection logic
  • full reliability architecture (Domain 7)

=== STRUCTURE ===

=== PART 1 — WHY ALARMS ARE NOT JUST MESSAGES ===

Explain:

  • alarms represent machine faults or abnormal conditions
  • they must:
    • inform the operator
    • guide action
    • prevent unsafe operation
    • support recovery

Explain:

  • why poor alarms cause:
    • confusion
    • wrong operator actions
    • longer downtime
    • repeated failures

Use examples:

  • vague error message vs actionable guidance
  • alarm flood hiding root cause

=== PART 2 — ALARM CLASSIFICATION & SEVERITY ===

Explain typical severity levels:

  • Info / Notice
  • Warning
  • Error / Fault
  • Critical / Safety

Explain:

  • how severity affects:
    • UI presentation
    • machine behavior (continue / stop / inhibit)
    • operator attention

Explain:

  • why consistent classification matters

=== PART 3 — ALARM LIFECYCLE ===

Explain lifecycle:

  1. Detected
  2. Raised (becomes active)
  3. Displayed to operator
  4. Acknowledged
  5. Condition resolved
  6. Cleared / reset

Explain:

  • difference between:
    • acknowledged vs cleared
    • transient vs persistent alarms

Include ASCII lifecycle diagram

=== PART 4 — OPERATOR GUIDANCE ===

Explain:

  • alarms should not only say “what failed”
  • they should help answer:
    • what happened?
    • why?
    • what should I do next?

Explain good guidance:

  • clear description
  • possible causes
  • recommended actions
  • required actions before reset

Explain:

  • difference between operator-facing vs engineer/service guidance

=== PART 5 — ALARM INTEGRATION WITH MACHINE STATE ===

Explain:

  • alarms affect machine behavior:
    • stop motion
    • block commands
    • change workflow state
    • require operator intervention

Explain:

  • why alarm state must be part of overall machine state model

Include ASCII flow: Fault → Alarm → Machine State Change → UI → Operator → Action → Recovery

=== PART 6 — ALARM PRESENTATION IN UI ===

Explain:

  • alarm panel/list
  • visual indicators (color, blinking, priority)
  • grouping and filtering
  • history vs active alarms

Explain:

  • importance of:
    • visibility
    • clarity
    • prioritization

=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===

Explain:

  • too many alarms (alarm flood)
  • unclear message → operator guesses wrong fix
  • alarm cleared but condition still exists
  • operator acknowledges without understanding
  • same root cause triggers multiple alarms
  • UI hides critical alarm behind less important ones
  • inconsistent alarm severity across subsystems

For each:

  • what it looks like
  • why it happens
  • how engineers fix it

=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===

Explain:

  • need for centralized alarm service
  • importance of:
    • consistent alarm model
    • severity definition
    • clear lifecycle management
    • mapping between fault detection and UI presentation
    • structured guidance content
    • alarm history logging
    • correlation with machine state and workflow

Explain good vs bad:

  • bad: scattered error messages, inconsistent severity, no lifecycle, no guidance
  • good: centralized alarm system, structured messages, clear lifecycle, integrated with state and workflow

Include ASCII component diagram: Device / Workflow / Vision ↓ Fault Detection ↓ Alarm Service ↓ UI Alarm Panel + Machine State + Logs

=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===

Give:

  • how to explain alarm systems clearly
  • why alarms must guide operator action
  • common mistakes software engineers make
  • what strong engineers understand about severity, lifecycle, and clarity

=== OUTPUT ===

  • structured explanation
  • real-world alarm and operator guidance insights
  • ASCII UML-style diagrams
  • practical language suitable for real systems and interviews

6.5 ​

You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).

You have real production experience, including:

  • designing HMI screens around real operator workflows
  • structuring machine UI navigation for production, setup, review, and recovery scenarios
  • reducing operator mistakes through clear screen hierarchy and workflow-aware design
  • debugging systems where poor screen design caused confusion, wrong actions, or slow recovery

I am a senior .NET engineer transitioning into this domain.

I want to deeply understand how operator workflows and screen design are structured in industrial machine software.

=== TOPIC === Operator Workflows & Screen Design

=== GOAL ===

Help me understand how industrial HMI screens are designed around real operator tasks and machine workflows.

Focus on:

  • operator workflow modeling
  • screen hierarchy and navigation
  • production vs setup vs recovery flows
  • reducing confusion and preventing operator mistakes

=== ALIGNMENT WITH SOURCE OF TRUTH ===

This topic corresponds to:

"Operator workflows & screen design"

Do NOT introduce unrelated topics.

=== STYLE & DEPTH ===

Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.

Focus on:

  • real operator behavior
  • practical workflow-driven UI architecture
  • production usability and safety

Avoid:

  • generic UI/UX theory
  • shallow screen lists
  • visual styling details

=== DIAGRAM STYLE ===

Use UML-style ASCII diagrams:

  • Screen flow diagrams → navigation and task flow
  • Workflow diagrams → operator task sequence
  • Component diagrams → screen/viewmodel responsibilities

Rules:

  • ASCII only
  • simple and readable
  • clearly explain each diagram

=== SCOPE CONTROL ===

Stay within:

  • operator workflows
  • screen organization
  • navigation and task flow

Do NOT deep dive into:

  • alarm system details (Topic 6.4)
  • chart/image visualization details (Topic 6.6)
  • service/manual control specifics (Topic 6.7)

=== STRUCTURE ===

=== PART 1 — WHY SCREEN DESIGN MUST FOLLOW OPERATOR WORKFLOW ===

Explain:

  • industrial UI should be organized around real work, not developer modules
  • operators need to:
    • start production
    • monitor progress
    • respond to alarms
    • inspect results
    • recover safely
  • screen design must reduce decisions under stress

Use examples:

  • wafer inspection run flow
  • production operator vs service engineer usage

=== PART 2 — COMMON OPERATOR WORKFLOWS ===

Explain typical workflows:

  • startup / login
  • machine readiness check
  • recipe/job selection
  • run start
  • live monitoring
  • alarm response
  • result review
  • stop/end run
  • recovery and restart

Explain:

  • why each workflow needs clear UI support

=== PART 3 — SCREEN HIERARCHY ===

Explain common screen groups:

  • home / machine overview
  • production/run screen
  • alarm screen
  • recipe/configuration screen
  • review/results screen
  • manual/service screen
  • diagnostics screen

Explain:

  • what belongs on each screen
  • what should not be mixed

Include ASCII screen hierarchy diagram

=== PART 4 — NAVIGATION DESIGN ===

Explain:

  • navigation must support real operator flow
  • critical screens must be reachable quickly
  • dangerous screens should require intentional access

Explain:

  • mode-aware navigation
  • role-aware navigation
  • context-preserving navigation

Include ASCII navigation flow diagram

=== PART 5 — CONTEXTUAL UI DESIGN ===

Explain:

  • screens should show relevant context:
    • current job/run
    • machine state
    • active recipe
    • alarms
    • current workflow step

Explain:

  • why context prevents wrong actions
  • why losing context during navigation causes mistakes

=== PART 6 — DESIGNING FOR RECOVERY FLOWS ===

Explain:

  • UI must support abnormal workflows:
    • alarm recovery
    • paused run
    • aborted sequence
    • manual intervention
    • partial completion

Explain:

  • why recovery screens need clear next actions
  • why recovery is often more important than happy-path production UI

=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===

Explain:

  • operator cannot find needed action under alarm
  • screen shows controls without enough machine context
  • production and service actions mixed together
  • navigation loses current run context
  • operator edits recipe while run is active
  • recovery flow unclear after abort
  • too much information causes missed critical status

For each:

  • what it looks like in production
  • why it happens
  • how experienced engineers fix it

=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===

Explain:

  • screen design affects architecture
  • importance of:
    • workflow-aware view models
    • central navigation service
    • shared machine context
    • role/mode-aware screen access
    • separation between production, setup, service, and diagnostics flows
    • consistent screen contracts

Explain good vs bad approaches:

  • bad: screens built around database/device structure, duplicated state per screen, no workflow context
  • good: screens organized around operator tasks, shared state model, controlled navigation, context-aware actions

Include ASCII component diagram if useful: Machine State / Workflow Context ↓ Navigation + Screen Context Service ↓ Production / Alarm / Recipe / Review Screens

=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===

Give:

  • how to explain operator workflow-driven UI design clearly
  • why screens should follow real work, not code modules
  • common mistakes software engineers make when entering industrial UI
  • what strong engineers understand about context, navigation, recovery, and operator stress

=== OUTPUT ===

  • structured explanation
  • real-world operator workflow and screen design insights
  • ASCII UML-style diagrams
  • practical language suitable for real systems and interviews

6.6 ​

You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).

You have real production experience, including:

  • designing real-time dashboards for machine status, health, and performance
  • visualizing time-series data, events, and system metrics without overloading the UI
  • integrating monitoring views with machine state, alarms, and workflows
  • debugging systems where poor visualization hid problems or misled operators

I am a senior .NET engineer transitioning into this domain.

I want to deeply understand how visualization and monitoring are designed in industrial HMIs from a SOFTWARE ARCHITECTURE perspective.

=== TOPIC === Visualization & Monitoring

=== GOAL ===

Help me understand how industrial systems present machine status, trends, and health information to operators effectively.

Focus on:

  • dashboards and status indicators
  • real-time charting and trends
  • data aggregation vs raw data
  • performance and clarity constraints
  • integration with machine state and alarms

=== ALIGNMENT WITH SOURCE OF TRUTH ===

This topic corresponds to:

"Visualization & monitoring"

Do NOT introduce unrelated topics.

=== STYLE & DEPTH ===

Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.

Focus on:

  • real-world monitoring behavior
  • performance vs clarity trade-offs
  • system-level data flow

Avoid:

  • charting library specifics
  • UI styling/theming discussions
  • shallow “draw charts” explanations

=== DIAGRAM STYLE ===

Use UML-style ASCII diagrams:

  • Data flow diagrams → machine → aggregation → UI
  • Dashboard layout diagrams → logical grouping of information
  • Sampling/aggregation diagrams → raw vs displayed data

Rules:

  • ASCII only
  • simple and readable
  • clearly explain each diagram

=== SCOPE CONTROL ===

Stay within:

  • monitoring and visualization of system state and metrics
  • dashboards and charts

Do NOT deep dive into:

  • image visualization (covered in Domain 5)
  • alarm system design (Topic 6.4)
  • workflow navigation (Topic 6.5)

=== STRUCTURE ===

=== PART 1 — WHY MONITORING IS NOT JUST “DISPLAY DATA” ===

Explain:

  • monitoring helps operators answer:
    • is the machine healthy?
    • is production stable?
    • are trends normal?
    • are problems developing?
  • good visualization:
    • surfaces important information quickly
    • hides noise
    • supports decision-making

Explain:

  • why bad visualization causes:
    • missed problems
    • incorrect conclusions
    • slower reaction time

=== PART 2 — TYPES OF MONITORING DATA ===

Explain categories:

  • machine state (running, idle, fault)
  • motion data (position, speed)
  • process data (temperature, pressure, vacuum, etc.)
  • vision metrics (inspection rate, defect counts)
  • performance metrics (throughput, cycle time)
  • system health (CPU, memory, IO)
  • alarms/events

Explain:

  • why different data types require different visualization styles

=== PART 3 — DASHBOARD DESIGN ===

Explain:

  • dashboards aggregate key information into a single view
  • typical structure:
    • high-level status indicators
    • key metrics
    • alarms summary
    • trends

Explain:

  • importance of:
    • hierarchy (critical → detailed)
    • grouping
    • consistency

Include ASCII dashboard layout diagram

=== PART 4 — REAL-TIME CHARTING & TRENDS ===

Explain:

  • charts show how values change over time
  • use cases:
    • detecting drift
    • identifying instability
    • comparing before/after

Explain:

  • sliding window vs historical view
  • sampling frequency vs performance
  • smoothing vs raw data

=== PART 5 — DATA SAMPLING & AGGREGATION ===

Explain:

  • raw data may be too frequent for UI
  • need to:
    • sample (e.g., 10–20 Hz for display)
    • aggregate (min/max/avg over window)
    • compress data

Explain:

  • difference between:
    • control data (full precision)
    • display data (human-readable)

Include ASCII diagram: Raw Data Stream → Sampling/Aggregation → UI Display

=== PART 6 — PERFORMANCE & SCALABILITY CONSTRAINTS ===

Explain:

  • too many charts or high-frequency updates can:
    • freeze UI
    • increase CPU/GPU usage
    • impact overall system performance

Explain strategies:

  • limit update frequency
  • decouple data pipeline from UI
  • reuse buffers
  • virtualize UI elements

=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===

Explain:

  • chart shows delayed data → operator thinks system is stable
  • dashboard hides critical alarm behind less important data
  • too many metrics → operator ignores everything
  • sampling hides transient spikes
  • UI freezes due to heavy chart updates
  • inconsistent scaling between charts leads to wrong interpretation

For each:

  • what it looks like
  • why it happens
  • how experienced engineers fix it

=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===

Explain:

  • monitoring requires a data pipeline separate from UI
  • importance of:
    • data aggregation services
    • sampling policies
    • consistent units/scaling
    • linking metrics to machine state and alarms
    • configurable dashboards

Explain good vs bad:

  • bad: UI pulls raw data directly, unbounded updates, inconsistent metrics
  • good: structured monitoring pipeline, aggregated data, controlled UI updates, clear hierarchy

Include ASCII component diagram: Machine State / Sensors ↓ Monitoring Data Pipeline ↓ Aggregation / Sampling ↓ Dashboard / Charts UI

=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===

Give:

  • how to explain monitoring systems clearly
  • why visualization must balance clarity and performance
  • common mistakes software engineers make when entering industrial UI
  • what strong engineers understand about aggregation, sampling, and operator cognition

=== OUTPUT ===

  • structured explanation
  • real-world visualization and monitoring insights
  • ASCII UML-style diagrams
  • practical language suitable for real systems and interviews

6.7 ​

You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).

You have real production experience, including:

  • designing manual control and service interfaces for machine setup, maintenance, and troubleshooting
  • exposing powerful engineering controls without bypassing safety and state rules
  • supporting service engineers during commissioning, calibration, and fault recovery
  • debugging systems where manual/service screens caused unsafe actions or inconsistent machine state

I am a senior .NET engineer transitioning into this domain.

I want to deeply understand how service, manual control, and engineering interfaces are designed safely in industrial HMIs.

=== TOPIC === Service, Manual Control & Engineering Interfaces

=== GOAL ===

Help me understand how industrial HMIs expose advanced controls for service engineers and technical users.

Focus on:

  • manual control screens
  • service / maintenance interfaces
  • engineering diagnostics
  • safe exposure of powerful machine actions
  • differences between operator UI and service UI

=== ALIGNMENT WITH SOURCE OF TRUTH ===

This topic corresponds to:

"Service, manual control & engineering interfaces"

Do NOT introduce unrelated topics.

=== STYLE & DEPTH ===

Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.

Focus on:

  • real-world service workflows
  • safety and control boundaries
  • practical HMI architecture

Avoid:

  • generic admin UI theory
  • shallow descriptions of “maintenance screens”
  • unsafe suggestions that bypass interlocks

=== DIAGRAM STYLE ===

Use UML-style ASCII diagrams:

  • Mode diagrams → production vs service/manual mode
  • Command flow diagrams → manual command validation
  • Screen responsibility diagrams → service tools and diagnostics

Rules:

  • ASCII only
  • simple and readable
  • clearly explain each diagram

=== SCOPE CONTROL ===

Stay within:

  • service UI
  • manual control UI
  • engineering interfaces
  • safe technical access

Do NOT deep dive into:

  • role/access control details (Topic 6.9)
  • recipe editing (Topic 6.8)
  • full safety certification standards

=== STRUCTURE ===

=== PART 1 — WHY SERVICE INTERFACES EXIST ===

Explain:

  • production operators need simple, guided workflows
  • service/engineering users need deeper access for:
    • setup
    • commissioning
    • calibration
    • troubleshooting
    • recovery
    • diagnostics

Explain:

  • why service UI is powerful and risky

Use examples:

  • jog axis
  • toggle vacuum
  • trigger camera
  • read raw IO
  • reset device
  • run calibration step

=== PART 2 — OPERATOR UI VS SERVICE UI ===

Explain the difference:

Operator UI:

  • task-focused
  • constrained
  • production-safe
  • minimal decisions

Service UI:

  • diagnostic-focused
  • more detailed
  • exposes lower-level controls
  • requires higher skill

Explain:

  • why mixing them causes confusion and risk

Include ASCII comparison diagram.

=== PART 3 — MANUAL CONTROL DESIGN ===

Explain:

  • manual controls allow direct or semi-direct control of subsystems
  • examples:
    • axis jog
    • move to position
    • turn output on/off
    • open/close clamp
    • trigger acquisition

Explain:

  • manual control must still go through:
    • state validation
    • mode validation
    • interlock checks
    • resource ownership checks
    • command logging

Include ASCII command flow diagram: Service UI → Manual Command Request → Validation → Machine Controller → Device

=== PART 4 — SERVICE MODE & MAINTENANCE MODE ===

Explain:

  • service/maintenance mode changes what actions are allowed
  • it should not mean “ignore safety”
  • some workflows may be disabled while service mode is active

Explain:

  • mode entry/exit rules
  • why machine must return to known state before production resumes

Include ASCII mode diagram.

=== PART 5 — ENGINEERING DIAGNOSTICS INTERFACES ===

Explain service tools may expose:

  • raw device status
  • IO monitor
  • communication trace
  • motion status
  • vision diagnostic data
  • logs and fault history
  • calibration status
  • health metrics

Explain:

  • why diagnostic information must be meaningful, not just raw values

=== PART 6 — RECOVERY AND TROUBLESHOOTING FLOWS ===

Explain:

  • service interfaces often support recovery from abnormal states
  • examples:
    • recover from failed homing
    • release stuck part
    • reinitialize camera
    • clear jam condition
    • verify sensor state

Explain:

  • why recovery actions must be step-guided where possible
  • why manual recovery without context is dangerous

=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===

Explain:

  • service screen toggles output while workflow still owns device
  • manual jog allowed while guard/interlock unsafe
  • operator uses service screen to bypass normal process
  • service mode left active after maintenance
  • diagnostic screen shows raw values without meaning
  • manual action fixes symptom but leaves workflow state inconsistent
  • engineering command not logged, so root cause cannot be traced

For each:

  • what it looks like in production
  • why it happens
  • how experienced engineers prevent or diagnose it

=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===

Explain:

  • service/manual UI must be architected as a controlled interface, not a shortcut
  • importance of:
    • command gateway reuse
    • mode-aware behavior
    • resource ownership checks
    • audit logging
    • guided recovery actions
    • clear separation from production UI
    • visibility of current machine state before action

Explain good vs bad approaches:

  • bad: service UI directly calls device APIs, hidden bypass switches, no logging
  • good: service UI uses same validated command path with additional service-only permissions and diagnostics

Include ASCII component diagram: Service / Manual UI ↓ Command Gateway + Safety Validation ↓ Machine Controller / Subsystem ↓ Device Layer ↓ Diagnostics / Audit Trail

=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===

Give:

  • how to explain service/manual interfaces clearly
  • why service mode is not a safety bypass
  • common mistakes software engineers make when entering industrial HMI
  • what strong engineers understand about guided recovery, resource ownership, and traceable service actions

=== OUTPUT ===

  • structured explanation
  • real-world service/manual UI insights
  • ASCII UML-style diagrams
  • practical language suitable for real systems and interviews

6.8 ​

You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).

You have real production experience, including:

  • designing recipe editors and configuration screens for production machines
  • preventing unsafe or invalid parameter changes from reaching machine execution
  • handling validation, approval, activation, and auditability of configuration changes
  • debugging systems where poor recipe/configuration UI caused wrong production behavior, equipment risk, or quality issues

I am a senior .NET engineer transitioning into this domain.

I want to deeply understand how recipe and configuration UIs are designed safely in industrial HMIs.

=== TOPIC === Recipe & Configuration UI

=== GOAL ===

Help me understand how industrial HMIs expose recipe and configuration editing without creating unsafe or unstable machine behavior.

Focus on:

  • recipe editor design
  • configuration screens
  • validation and activation flows
  • preventing unsafe parameter changes
  • operator/engineer clarity and traceability

=== ALIGNMENT WITH SOURCE OF TRUTH ===

This topic corresponds to:

"Recipe & configuration UI"

Do NOT introduce unrelated topics.

=== STYLE & DEPTH ===

Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.

Focus on:

  • real production usage
  • safety and validation
  • workflow-aware UI behavior
  • system-level architecture

Avoid:

  • generic form-design advice
  • shallow CRUD editor examples
  • detailed database schema design

=== DIAGRAM STYLE ===

Use UML-style ASCII diagrams:

  • State diagrams → recipe draft / validated / active lifecycle
  • Flow diagrams → edit → validate → approve → activate
  • Component diagrams → UI, validator, recipe manager, machine state

Rules:

  • ASCII only
  • simple and readable
  • clearly explain each diagram

=== SCOPE CONTROL ===

Stay within:

  • recipe/configuration editing UI
  • validation, activation, auditability
  • safe operator/engineer interaction

Do NOT deep dive into:

  • recipe data architecture already covered in Domain 1
  • role/access control details (Topic 6.9)
  • full MES recipe integration

=== STRUCTURE ===

=== PART 1 — WHY RECIPE / CONFIGURATION UI IS RISKY ===

Explain:

  • recipe and configuration screens do not just edit data
  • they can change:
    • motion positions
    • speed limits
    • inspection thresholds
    • camera/light settings
    • timing values
    • enable/disable behavior

Explain:

  • bad parameter changes can cause:
    • poor inspection quality
    • machine crash
    • unsafe motion
    • production drift
    • hard-to-debug behavior

Use examples:

  • operator changes scan speed but exposure is no longer valid
  • engineer edits motion offset while machine is running
  • wrong recipe activated for wafer type

=== PART 2 — RECIPE EDITING VS CONFIGURATION EDITING ===

Explain the difference:

Recipe UI:

  • product/process-specific
  • changed more often
  • used for production variants

Configuration UI:

  • machine/site/device-specific
  • changed less often
  • often requires engineer/service access

Explain:

  • why mixing them in one generic settings screen is dangerous

Include ASCII comparison diagram if useful.

=== PART 3 — EDITING LIFECYCLE ===

Explain lifecycle:

  1. Open existing recipe/config
  2. Edit draft values
  3. Validate locally
  4. Validate against machine constraints
  5. Review changes
  6. Approve / save
  7. Activate
  8. Confirm machine/subsystems applied correctly

Explain:

  • why “save” is not always “active”
  • why activation must be controlled

Include ASCII flow diagram.

=== PART 4 — VALIDATION IN THE UI AND BACKEND ===

Explain:

  • UI validation helps users correct mistakes early
  • backend validation is the real authority

Validation types:

  • required fields
  • ranges
  • units
  • cross-parameter dependencies
  • hardware capability checks
  • recipe/machine compatibility
  • mode/state constraints

Explain:

  • why validation must not exist only in UI

=== PART 5 — SAFE ACTIVATION FLOW ===

Explain:

  • changing active parameters while machine is running may be unsafe
  • some changes require:
    • machine idle
    • workflow stopped
    • subsystem reinitialization
    • confirmation
    • revalidation

Explain:

  • activation should clearly show:
    • what changed
    • what will be affected
    • whether restart/reload/recalibration is required

Include ASCII state diagram: Draft → Validated → Approved → Active → Archived

=== PART 6 — UI CLARITY FOR PARAMETERS ===

Explain:

  • parameter names must be meaningful to users
  • UI should show:
    • units
    • allowed range
    • default value
    • current active value
    • draft value
    • warning/impact message
    • dependency information

Explain:

  • why unclear parameter labels create production errors

=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===

Explain:

  • user edits value but active machine still uses old cached value
  • UI allows invalid combination of parameters
  • units unclear: mm vs µm
  • parameter hidden in advanced screen affects production unexpectedly
  • operator changes recipe during active run
  • wrong recipe version used after edit
  • validation passes in UI but fails during machine execution
  • no audit trail, so nobody knows who changed production setting

For each:

  • what it looks like in production
  • why it happens
  • how experienced engineers prevent or diagnose it

=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===

Explain:

  • recipe/config UI must be a workflow, not a raw editor
  • importance of:
    • draft vs active model
    • backend validation service
    • explicit activation command
    • change preview/diff
    • versioning
    • audit log
    • safe machine-state checks
    • clear user feedback when activation fails

Explain good vs bad approaches:

  • bad: direct edit of live values, magic settings grid, UI-only validation, silent fallback
  • good: controlled edit/validate/approve/activate flow with traceable changes and backend enforcement

Include ASCII component diagram: Recipe Editor UI ↓ Draft Model ↓ Validation Service ↓ Recipe / Config Manager ↓ Activation Command ↓ Machine / Subsystems ↓ Audit + Feedback

=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===

Give:

  • how to explain recipe/configuration UI clearly
  • why recipe UI is not simple CRUD
  • common mistakes software engineers make when entering industrial HMI
  • what strong engineers understand about validation, activation, traceability, and safe parameter changes

=== OUTPUT ===

  • structured explanation
  • real-world recipe/configuration UI insights
  • ASCII UML-style diagrams
  • practical language suitable for real systems and interviews

6.9 ​

You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).

You have real production experience, including:

  • designing role-based access control for industrial HMIs
  • restricting operator, engineer, service, and admin actions safely
  • auditing operator actions, recipe changes, command execution, and fault recovery
  • debugging production issues where missing audit trails made it impossible to know what changed or who did what

I am a senior .NET engineer transitioning into this domain.

I want to deeply understand how access control, auditability, and traceability are designed in industrial HMIs.

=== TOPIC === Access Control, Audit & Traceability

=== GOAL ===

Help me understand how industrial HMIs control who can do what, and how important actions are recorded for accountability and diagnosis.

Focus on:

  • role-based UI behavior
  • command and screen access control
  • auditability of operator actions
  • traceability of changes and decisions
  • production support and accountability

=== ALIGNMENT WITH SOURCE OF TRUTH ===

This topic corresponds to:

"Access control, audit & traceability"

Do NOT introduce unrelated topics.

=== STYLE & DEPTH ===

Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.

Focus on:

  • real production behavior
  • safety and accountability
  • practical HMI architecture

Avoid:

  • generic enterprise identity theory
  • deep cybersecurity treatment
  • shallow “hide buttons by role” explanations

=== DIAGRAM STYLE ===

Use UML-style ASCII diagrams:

  • Access flow diagrams → user → role → permission → command
  • Audit flow diagrams → action → validation → execution → audit record
  • Component diagrams → UI, authorization service, command gateway, audit log

Rules:

  • ASCII only
  • simple and readable
  • clearly explain each diagram

=== SCOPE CONTROL ===

Stay within:

  • HMI access control
  • operator/service permissions
  • audit and traceability of UI actions

Do NOT deep dive into:

  • cybersecurity infrastructure
  • network security
  • recipe editor internals
  • full compliance standards

=== STRUCTURE ===

=== PART 1 — WHY ACCESS CONTROL MATTERS IN INDUSTRIAL HMI ===

Explain:

  • different users should have different authority:
    • operator
    • supervisor
    • process engineer
    • service engineer
    • administrator
  • some actions are harmless to view but dangerous to execute

Use examples:

  • operator may start/stop job but not edit calibration
  • engineer may edit recipe but not bypass safety interlock
  • service engineer may jog axes only in maintenance mode

Explain:

  • why access control is also a safety and quality concern, not only security.

=== PART 2 — ROLES, PERMISSIONS, AND MACHINE MODES ===

Explain clearly:

  • role = who the user is
  • permission = what action they may request
  • mode = current machine operating context

Explain:

  • valid action often depends on all three:
    • user role
    • requested command
    • machine state/mode

Include ASCII diagram: User Role + Machine Mode + Current State → Allowed Actions

=== PART 3 — UI VISIBILITY VS BACKEND AUTHORIZATION ===

Explain:

  • UI can hide or disable unavailable actions
  • but backend must still enforce authorization

Explain:

  • why UI-only permissions are unsafe:
    • alternate screen path
    • API call
    • stale UI state
    • service tool path

Use example:

  • button hidden for operator, but command endpoint still accepts request

=== PART 4 — ACCESS CONTROL FOR SCREENS AND COMMANDS ===

Explain:

  • screen access:

    • who can open service screen
    • who can view diagnostics
    • who can edit recipes

  • command access:

    • who can activate recipe
    • who can reset alarm
    • who can jog axis
    • who can force output

Explain:

  • why command permissions matter more than screen permissions

Include ASCII access control flow: UI Action → Authorization Check → Safety Check → Execute / Reject

=== PART 5 — AUDITABILITY OF OPERATOR ACTIONS ===

Explain:

  • important actions must be recorded:
    • login/logout
    • start/stop/abort
    • manual control
    • recipe/config changes
    • alarm acknowledge/reset
    • service actions
    • override decisions

Explain:

  • audit record should include:
    • who
    • what
    • when
    • where/screen
    • machine state
    • command/result
    • previous value/new value where applicable

=== PART 6 — TRACEABILITY ACROSS ACTIONS, STATE, AND RESULTS ===

Explain:

  • traceability connects operator action to system behavior and production outcome

Examples:

  • recipe changed → run started → inspection failed
  • alarm acknowledged → recovery action → machine resumed
  • service jog command → alignment changed → production result drifted

Explain:

  • why audit logs should correlate with:
    • machine state
    • workflow context
    • recipe/version
    • alarms/events
    • production/run ID

Include ASCII traceability chain diagram.

=== PART 7 — REAL-WORLD FAILURE SCENARIOS ===

Explain:

  • operator changes setting but no audit record exists
  • service screen allows action beyond intended role
  • action hidden in UI but still executable through shortcut/API
  • alarm reset recorded but original fault context lost
  • recipe changed before run but nobody knows which version was active
  • supervisor override changes production outcome without trace
  • multiple users share one login

For each:

  • what it looks like in production
  • why it happens
  • how experienced engineers prevent or diagnose it

=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===

Explain:

  • access control and audit must be architectural services, not UI decorations
  • importance of:
    • central authorization service
    • command-level permission checks
    • machine-mode-aware access rules
    • immutable audit records
    • action correlation IDs
    • consistent identity/session handling
    • meaningful rejection messages
    • audit export/search for support

Explain good vs bad approaches:

  • bad: hide buttons only, shared passwords, no audit trail, unstructured text logs
  • good: centralized authorization, backend enforcement, structured audit records, correlation with machine/run context

Include ASCII component diagram: User Session ↓ UI ↓ Authorization Service ↓ Command Gateway ↓ Machine Controller ↓ Audit Trail + Traceability Store

=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===

Give:

  • how to explain access control and auditability clearly
  • why UI hiding is not real authorization
  • common mistakes software engineers make when entering industrial HMI
  • what strong engineers understand about roles, modes, command authorization, and traceability

=== OUTPUT ===

  • structured explanation
  • real-world access control and audit insights
  • ASCII UML-style diagrams
  • practical language suitable for real systems and interviews

6.10 ​

You are a Principal Software Architect with deep experience building industrial machine software (semiconductor equipment, robotics, automation systems, inspection machines).

You have real production experience, including:

  • designing HMIs used by operators under time pressure, noise, fatigue, and production stress
  • reducing operator mistakes through clear information hierarchy and safe interaction design
  • diagnosing UI-related failures where the software technically worked but misled users
  • improving systems where poor usability caused downtime, wrong recovery actions, or loss of trust

I am a senior .NET engineer transitioning into this domain.

I want to deeply understand how industrial HMIs are designed for real factory conditions and how UI failures happen in production.

=== TOPIC === Usability Under Real Conditions & Failure Modes

=== GOAL ===

Help me understand how industrial HMIs remain clear, safe, and usable under real operating conditions.

Focus on:

  • usability under stress
  • factory environment constraints
  • error prevention
  • operator cognition
  • real UI failure modes
  • designing HMIs that support correct action during abnormal situations

=== ALIGNMENT WITH SOURCE OF TRUTH ===

This topic corresponds to:

"Usability under real conditions & failure modes"

Do NOT introduce unrelated topics.

=== STYLE & DEPTH ===

Write at a PRINCIPAL ENGINEER / SOFTWARE ARCHITECT level.

Focus on:

  • real operator behavior
  • production pressure
  • safety and recovery
  • practical design trade-offs

Avoid:

  • generic UX theory
  • aesthetic design discussion
  • shallow “make UI simple” advice

=== DIAGRAM STYLE ===

Use UML-style ASCII diagrams:

  • Decision-flow diagrams → operator action under stress
  • Failure-mode diagrams → UI issue → wrong decision → machine impact
  • Screen hierarchy diagrams → critical vs secondary information
  • Feedback loop diagrams → machine state → UI → operator → command

Rules:

  • ASCII only
  • simple and readable
  • clearly explain each diagram

=== SCOPE CONTROL ===

Stay within:

  • usability under real factory/operator conditions
  • UI-driven failure modes
  • operator decision support

Do NOT deep dive into:

  • alarm system internals (Topic 6.4)
  • access control internals (Topic 6.9)
  • WPF control implementation details

=== STRUCTURE ===

=== PART 1 — WHY INDUSTRIAL HMI USABILITY IS DIFFERENT ===

Explain:

  • industrial HMIs are used in environments where operators may face:
    • production pressure
    • alarms
    • noise
    • interruptions
    • fatigue
    • gloves / limited input precision
    • shift handovers
    • limited technical context
  • usability affects:
    • safety
    • uptime
    • recovery speed
    • product quality
    • operator trust

Explain:

  • why “the UI technically works” is not enough.

Use examples:

  • operator chooses wrong recovery action because screen context is unclear
  • critical alarm hidden behind dense dashboard data
  • stale state displayed as current state

=== PART 2 — OPERATOR COGNITION UNDER STRESS ===

Explain:

  • under stress, users rely on:
    • visible cues
    • familiar patterns
    • clear next actions
    • simple choices
  • operators may not read long text carefully during faults
  • too much information can be as harmful as too little

Explain:

  • why screen design must reduce cognitive load.

Include ASCII diagram: Machine Problem → UI Signal → Operator Interpretation → Action → Machine Outcome

=== PART 3 — INFORMATION HIERARCHY & CLARITY ===

Explain:

  • UI should prioritize:
    1. machine state
    2. active faults / blocking conditions
    3. required operator action
    4. production context
    5. detailed diagnostics

Explain:

  • difference between:
    • information needed now
    • information needed for analysis
    • information needed by service engineers

Include ASCII screen hierarchy diagram.

=== PART 4 — ERROR PREVENTION DESIGN ===

Explain practical strategies:

  • disable unsafe actions
  • require confirmation for dangerous actions
  • explain why command is unavailable
  • avoid ambiguous labels
  • prevent mode confusion
  • show current context before action
  • make destructive actions intentional
  • provide clear recovery guidance

Explain:

  • why preventing a bad action is better than detecting it afterward.

=== PART 5 — FEEDBACK, TRUST, AND OPERATOR CONFIDENCE ===

Explain:

  • operators need feedback after actions:
    • command accepted
    • command rejected
    • command executing
    • command completed
    • command failed

Explain:

  • why delayed or missing feedback creates repeated clicks, retries, or distrust
  • why UI must distinguish:
    • command sent
    • command accepted
    • command physically completed

Include ASCII feedback loop diagram.

=== PART 6 — FACTORY CONDITIONS THAT AFFECT UI DESIGN ===

Explain practical constraints:

  • touchscreens with gloves
  • low/high lighting
  • operator standing posture
  • noisy alarms/environment
  • multilingual teams
  • limited training
  • shift changes
  • remote/service support
  • screen viewed from distance

Explain:

  • how these affect:
    • font sizes
    • button sizes
    • wording
    • color usage
    • screen density
    • navigation depth

Keep it practical, not aesthetic.

=== PART 7 — REAL-WORLD UI FAILURE MODES ===

Explain:

  • UI shows stale machine state as current
  • operator cannot tell what action is required
  • alarm/recovery text is too vague
  • button label is ambiguous
  • screen navigation hides critical context
  • UI allows action in wrong mode
  • success message shown before physical completion
  • too many warnings cause alarm fatigue
  • inconsistent terminology across screens
  • service/debug information shown to production operator causes confusion

For each:

  • what it looks like in production
  • why it happens
  • how experienced engineers fix it

=== PART 8 — SOFTWARE DESIGN IMPLICATIONS ===

Explain:

  • usability must influence architecture, not just screen layout
  • importance of:
    • state freshness indicators
    • clear command result model
    • mode-aware UI behavior
    • centralized terminology
    • consistent screen patterns
    • operator/action context
    • workflow-guided recovery
    • separation of operator-facing vs engineer-facing diagnostics
    • usability review with real users

Explain good vs bad approaches:

  • bad: dense screens, unclear command feedback, generic error text, hidden stale state, inconsistent labels
  • good: task-focused screens, clear next action, state freshness, command lifecycle feedback, guided recovery

Include ASCII component diagram: Machine State + Workflow Context ↓ UI Context / Presentation Model ↓ Operator Screen ↓ Operator Action ↓ Validated Command Path ↓ Machine Feedback

=== PART 9 — INTERVIEW / REAL-WORLD TALKING POINTS ===

Give:

  • how to explain HMI usability under factory conditions clearly
  • why usability is a safety and reliability concern
  • common mistakes software engineers make when entering industrial UI
  • what strong engineers understand about operator cognition, feedback, clarity, and failure modes

=== OUTPUT ===

  • structured explanation
  • real-world usability and UI failure insights
  • ASCII UML-style diagrams
  • practical language suitable for real systems and interviews

Docs-first project memory for AI-assisted implementation.

LCN Wafer Inspection Prototype