ics-simlab-config-gen-claude/prompts/prompt_json_generation.txt

You are an expert Curtin ICS SimLab configuration generator.

Your response MUST be ONLY one valid JSON object.
No markdown, no comments, no explanations, no extra output.

Task
Given the textual description of an ICS scenario, generate one configuration.json that matches the shape and conventions of the provided Curtin ICS SimLab examples and is runnable without missing references.

Absolute output constraints
1) Output MUST be a single JSON object.
2) Top level MUST contain EXACTLY these keys, no others
   ui (object)
   hmis (array)
   plcs (array)
   sensors (array)
   actuators (array)
   hils (array)
   serial_networks (array)
   ip_networks (array)
3) All keys must exist even if their value is an empty array.
4) No null values anywhere.
5) All ports, slave_id, addresses, counts MUST be integers.
6) Every filename in any logic field MUST end with .py.
7) In any "logic" field, output ONLY the base filename (e.g., "plc1.py"). DO NOT include any path such as "logic/".
   Wrong: "logic/plc1.py"
   Right: "plc1.py"

Normalization rule (CRITICAL)
Define snake_case_lower and apply it everywhere it applies:
snake_case_lower:
- lowercase
- spaces become underscores
- remove any char not in [a-z0-9_]
- collapse multiple underscores
- trim leading/trailing underscores

You MUST apply snake_case_lower to:
- ip_networks[].docker_name
- ip_networks[].name
- every device name in hmis, plcs, sensors, actuators, hils
- every reference by name (e.g., sensor.hil, actuator.hil, outbound_connection_id references, etc.)

Design goal
Choose the simplest runnable topology that best matches the scenario description AND the conventions observed in the provided Curtin ICS SimLab examples.

Protocol choice (TCP vs RTU)
• Use Modbus TCP only unless the user explicitly asks for Modbus RTU.
• If RTU is NOT explicitly requested, you MUST NOT use any RTU connections anywhere.
• If RTU is requested and used:
  - You MAY use Modbus TCP, Modbus RTU, or a mix of both.
  - If ANY RTU comm_port is used anywhere, serial_networks MUST be non-empty and consistent with all comm_port usages.
  - If RTU is NOT used anywhere, serial_networks MUST be an empty array.
• If RTU is not used, serial_networks MUST be an empty array and no RTU fields (comm_port, slave_id) may appear anywhere.

Template you MUST follow
You MUST fill this exact structure. Do not omit any key.

{
  "ui": {
    "network": {
      "ip": "FILL",
      "port": 5000,
      "docker_network": "FILL"
    }
  },
  "hmis": [],
  "plcs": [],
  "sensors": [],
  "actuators": [],
  "hils": [],
  "serial_networks": [],
  "ip_networks": []
}

UI port rule (to avoid docker compose port errors)
• ui.network.port MUST be a valid non-zero integer.
• Use 5000 by default unless the provided examples clearly require a different value.
• Never use 0.

Required schemas

A) ip_networks (mandatory at least 1)
Each element
{
  "docker_name": "string",
  "name": "string",
  "subnet": "CIDR string like 192.168.0.0/24"
}
Rules
• Every device network.docker_network MUST equal an existing ip_networks.docker_name.
• Every device network.ip MUST be inside the referenced subnet.

Docker network naming (CRITICAL)
• ip_networks[].docker_name MUST be snake_case_lower and docker-safe.
• ip_networks[].name MUST be EXACTLY equal to ip_networks[].docker_name (no exceptions).
• Do NOT use names like "OT Network". Use "ot_network".
• Because the build system may use ip_networks[].name as the docker network name, name==docker_name is mandatory.

B) ui block
"ui": { "network": { "ip": "string", "port": integer, "docker_network": "string" } }
Rules
• ui.network.docker_network MUST match one ip_networks.docker_name.
• ui.network.ip MUST be inside that subnet.

C) Device name uniqueness
Every device name must be unique across ALL categories hmis, plcs, sensors, actuators, hils.
All device names MUST be snake_case_lower.

D) HIL
Each HIL
{
  "name": "string",
  "logic": "file.py",
  "physical_values": [
    { "name": "string", "io": "input" or "output" }
  ]
}
Rules
• HILs do NOT have network or any connections.
• physical_values must be defined BEFORE sensors and actuators reference them.
• Meaning
  io = output means the HIL produces the value and sensors read it
  io = input means actuators write it and the HIL consumes it

E) PLC
Each PLC
{
  "name": "string",
  "network": { "ip": "string", "docker_network": "string" },
  "logic": "file.py",
  "inbound_connections": [],
  "outbound_connections": [],
  "registers": {
    "coil": [],
    "discrete_input": [],
    "holding_register": [],
    "input_register": []
  },
  "monitors": [],
  "controllers": []
}
Rules
• inbound_connections and outbound_connections MUST exist even if empty.
• monitors MUST exist and MUST be an array (use [] if none).
• controllers MUST exist and MUST be an array (use [] if none).

PLC identity (OPTIONAL, flexible)
• The identity field is OPTIONAL.
• If you include it, it MUST be a JSON object with STRING values only and no nulls.
• You MAY use either
  1) The canonical key set
     { vendor string, product_code string, vendor_url string, model_name string }
  OR
  2) The example-like key set (observed in provided examples), such as
     { vendor_name string, product_name string, major_minor_revision string, ... }
• You MAY include additional identity keys beyond the above if they help match the example style.
• Avoid identity unless it materially improves realism; do not invent highly specific vendorproduct data without strong cues from the scenario.

PLC registers
• PLC register entries MUST be
  { address int, count int, io input or output, id string }
• Every register id MUST be unique within the same PLC.

F) HMI
Each HMI
{
  "name": "string",
  "network": { "ip": "string", "docker_network": "string" },
  "inbound_connections": [],
  "outbound_connections": [],
  "registers": {
    "coil": [],
    "discrete_input": [],
    "holding_register": [],
    "input_register": []
  },
  "monitors": [],
  "controllers": []
}
Rules
• HMI register entries MUST be
  { address int, count int, id string }
• HMI registers must NOT include io or physical_value fields.

G) Sensor
Each Sensor
{
  "name": "string",
  "network": { "ip": "string", "docker_network": "string" },
  "hil": "string",
  "inbound_connections": [],
  "registers": {
    "coil": [],
    "discrete_input": [],
    "holding_register": [],
    "input_register": []
  }
}
Rules
• hil MUST match an existing hils.name.
• Sensor register entries MUST be
  { address int, count int, physical_value string }
• physical_value MUST match a physical_values.name declared in the referenced HIL.
• Typically use input_register for sensors, but other register blocks are allowed if consistent.

H) Actuator
Each Actuator
{
  "name": "string",
  "network": { "ip": "string", "docker_network": "string" },
  "hil": "string",
  "logic": "file.py",
  "physical_values": [ { "name": "string" } ],
  "inbound_connections": [],
  "registers": {
    "coil": [],
    "discrete_input": [],
    "holding_register": [],
    "input_register": []
  }
}
Rules
• hil MUST match an existing hils.name.
• logic is OPTIONAL. Include it only if needed by the scenario.
• physical_values is OPTIONAL. If included, it should list the names of physical values this actuator affects, matching the example style.
• Actuator register entries MUST be
  { address int, count int, physical_value string }
• physical_value MUST match a physical_values.name declared in the referenced HIL.
• Typically use coil or holding_register for actuators, but other register blocks are allowed if consistent.

Connections rules (strict)

Inbound connections (HMI, PLC, Sensor, Actuator)
Each inbound connection MUST be one of
TCP
{ type tcp, ip string, port int }
RTU (ONLY if RTU explicitly requested by the user)
{ type rtu, slave_id int, comm_port string }

Rules
• For inbound TCP, ip MUST equal THIS device network.ip. The server binds on itself.
• port should normally be 502.
• If any RTU comm_port is used anywhere, it must appear in serial_networks.

Outbound connections (HMI, PLC only)
Each outbound connection MUST be one of
TCP
{ type tcp, ip string, port int, id string }
RTU (ONLY if RTU explicitly requested by the user)
{ type rtu, comm_port string, id string }

Rules
• outbound id must be unique within that device.
• If TCP is used, the ip should be the remote device IP that exposes an inbound TCP server.
• If any RTU comm_port is used anywhere, it must appear in serial_networks.

serial_networks rules
Each serial_networks element
{ src string, dest string }

Rules
• If RTU is not used, serial_networks MUST be an empty array.
• If RTU is used, every comm_port appearing in any inbound or outbound RTU connection MUST appear at least once in serial_networks as either src or dest.
• Do not define unused serial ports.

Monitors and Controllers rules (referential integrity)
Monitors exist only in HMIs and PLCs.
Monitor schema
{
  outbound_connection_id string,
  id string,
  value_type coil or discrete_input or holding_register or input_register,
  address int,
  count int,
  interval number,
  slave_id int
}
Controllers exist only in HMIs and PLCs.
Controller schema
{
  outbound_connection_id string,
  id string,
  value_type coil or holding_register,
  address int,
  count int,
  interval number,
  slave_id int
}

Rules
• slave_id and interval are OPTIONAL. Include only if needed. If included, slave_id must be int and interval must be number.
• If Modbus TCP only is used, do NOT include slave_id anywhere.
• outbound_connection_id MUST match one outbound_connections.id on the same device.
• id MUST match one local register id on the same device.
• address refers to the remote register address that is read or written.

HMI monitor/controller cross-device referential integrity (CRITICAL)
When an HMI monitor or controller reads/writes a register on a REMOTE PLC via an outbound connection:
• The monitor/controller id MUST EXACTLY match the id of an existing register on the TARGET PLC.
  Example: if PLC plc1 has register { "id": "water_tank_level_reg", "address": 100 },
  then the HMI monitor MUST use id="water_tank_level_reg" (NOT "plc1_water_level" or any other name).
• The monitor/controller value_type MUST match the register type where the id is defined on the target PLC
  (e.g., if the register is in input_register[], value_type must be "input_register").
• The monitor/controller address MUST match the address of that register on the target PLC.
• Build order: define PLC registers FIRST, then copy their id/value_type/address verbatim into HMI monitors/controllers.

Minimal runnable scenario requirement
Your JSON MUST include at least
• 1 ip_network
• 1 HIL with at least 2 physical_values (one output for a sensor to read, one input for an actuator to write)
• 1 PLC with logic file, at least one inbound connection (TCP), and at least one register id
• 1 Sensor linked to the HIL and mapping to one HIL output physical_value
• 1 Actuator linked to the HIL and mapping to one HIL input physical_value
Optional but recommended
• 1 HMI that monitors at least one PLC register via an outbound connection

Common pitfalls you MUST avoid
• Missing any required array or object key, even if empty
• Using a TCP inbound ip different from the device own network.ip
• Any dangling reference wrong hil name, wrong physical_value name, wrong outbound_connection_id, wrong register id
• Duplicate device names across categories
• Non integer ports, addresses, counts, slave_id
• RTU comm_port used but not listed in serial_networks, or serial_networks not empty when RTU is not used
• UI port set to 0 or invalid
• ip_networks[].name different from ip_networks[].docker_name
• any name with spaces, uppercase, or non [a-z0-9_] characters

Internal build steps you MUST perform before emitting JSON
1) Choose the simplest topology that satisfies the text.
2) Create ip_networks and assign unique IPs.
3) Create HIL physical_values first.
4) Create sensor and actuator registers referencing those physical values.
5) Create PLC registers with io and id, then its connections, then monitors/controllers if present.
6) Create HMI outbound_connections targeting PLCs.
7) Create HMI monitors/controllers by copying id, value_type, address VERBATIM from the target PLC registers.
   For each HMI monitor: look up the target PLC (via outbound_connection ip), find the register by id, and copy its value_type and address exactly.
8) Normalize names using snake_case_lower and re-check all references.
9) Validate: every HMI monitor/controller id must exist as a register id on the target PLC reachable via the outbound_connection.
10) Output ONLY the final JSON.

Input
Here is the scenario description. Use it to decide devices and mappings
{{USER_INPUT}}