102 lines
5.1 KiB
Plaintext
102 lines
5.1 KiB
Plaintext
You are fixing a Curtin ICS-SimLab configuration.json so it does NOT crash the builder.
|
|
|
|
Output MUST be ONLY one valid JSON object.
|
|
No markdown, no comments, no extra text.
|
|
|
|
Inputs
|
|
Scenario:
|
|
{{USER_INPUT}}
|
|
|
|
Validation errors:
|
|
{{ERRORS}}
|
|
|
|
Current JSON:
|
|
{{CURRENT_JSON}}
|
|
|
|
Primary goal
|
|
Fix the JSON so that ALL listed validation errors are resolved in ONE pass.
|
|
Keep what is correct. Change/remove ONLY what is required to fix an error or prevent obvious builder breakage.
|
|
|
|
Hard invariants (must hold after repair)
|
|
A) Top-level shape (match examples)
|
|
1) 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)
|
|
2) All 8 keys MUST exist (use empty arrays if needed). No null anywhere.
|
|
3) Every registers block MUST contain all 4 arrays:
|
|
coil, discrete_input, holding_register, input_register
|
|
(use empty arrays if needed).
|
|
|
|
B) Network validity
|
|
1) Every device network must have: ip (string), docker_network (string).
|
|
2) Every docker_network value used anywhere MUST exist in ip_networks[].docker_name.
|
|
3) Keep ui.network.ip and ui.network.port unchanged unless an error explicitly requires a change.
|
|
(In examples, ui is on 192.168.0.111:8501 on vlan1.)
|
|
|
|
C) Numeric types
|
|
All numeric fields MUST be integers, never strings:
|
|
port, slave_id, address, count, interval.
|
|
|
|
D) IP uniqueness rules
|
|
1) Every (docker_network, ip) pair must be unique across hmis, plcs, sensors, actuators.
|
|
2) Do not reuse a PLC IP for any sensor or actuator.
|
|
3) If duplicates exist, keep the first occurrence unchanged and reassign ALL other conflicting devices.
|
|
Use a sequential scheme in the same /24 (e.g., 192.168.0.10..192.168.0.250),
|
|
skipping ui ip and any already-used IPs. No repeats.
|
|
4) After reassignments, update ALL references to the changed device IPs everywhere
|
|
(outbound_connections ip targets, HMI outbound_connections, etc.).
|
|
5) Re-check internally: ZERO duplicate (docker_network, ip).
|
|
|
|
E) Connection coherence (match examples)
|
|
1) For any tcp inbound_connection, it MUST contain:
|
|
type="tcp", ip (string), port (int).
|
|
For plc/sensor/actuator inbound tcp, set inbound ip equal to the device's own ip unless errors require otherwise.
|
|
2) For outbound tcp connections: MUST contain type="tcp", ip, port (int), id (string).
|
|
The target ip should match an existing device ip in the same docker_network.
|
|
3) For outbound rtu connections: MUST contain type="rtu", comm_port (string), id (string).
|
|
For inbound rtu connections: MUST contain type="rtu", slave_id (int), comm_port (string).
|
|
4) Every monitors[].outbound_connection_id and controllers[].outbound_connection_id MUST reference an existing
|
|
outbound_connections[].id within the same device.
|
|
5) value_type in monitors/controllers MUST be one of:
|
|
coil, discrete_input, holding_register, input_register.
|
|
|
|
F) Serial network sanity (only if RTU is used)
|
|
If any rtu comm_port is used in inbound/outbound connections, serial_networks MUST include the needed links
|
|
between the corresponding ttyS ports (follow the example pattern: plc ttySx ↔ device ttySy).
|
|
|
|
G) HIL references
|
|
Every sensor/actuator "hil" field MUST match an existing hils[].name.
|
|
|
|
H) Do not invent complexity
|
|
1) Do NOT add new devices unless errors explicitly require it.
|
|
2) Do NOT rename existing device "name" fields unless errors explicitly require it.
|
|
3) Do NOT change logic filenames unless errors explicitly require it. If you must set a logic value, it must end with ".py".
|
|
|
|
I) HMI monitor/controller cross-device referential integrity (CRITICAL)
|
|
When an HMI monitor or controller references a register on a remote PLC:
|
|
1) The monitor/controller id MUST EXACTLY match an existing registers[].id on the TARGET PLC
|
|
(the PLC whose IP matches the outbound_connection used by the monitor).
|
|
2) The monitor/controller value_type MUST match the register type on the target PLC
|
|
(e.g., if the register is in input_register[], value_type must be "input_register").
|
|
3) The monitor/controller address MUST match the address of that register on the target PLC.
|
|
4) If a SEMANTIC ERROR says "Register 'X' not found on plc 'Y'", look up plc Y's registers
|
|
and change the monitor/controller id to match an actual register id on that PLC.
|
|
Then also fix value_type and address to match.
|
|
|
|
Conditional requirement (apply ONLY if explicitly demanded by ERRORS)
|
|
If ERRORS require minimum HMI registers/monitors, satisfy them using the simplest approach:
|
|
- Prefer adding missing registers/monitors to an existing HMI that already has a valid outbound connection to a PLC.
|
|
- Do not create extra networks or extra devices to satisfy this.
|
|
|
|
Final internal audit before output
|
|
- Top-level keys exactly 8, no extras
|
|
- No nulls
|
|
- All numeric fields are integers
|
|
- docker_network references exist in ip_networks
|
|
- No duplicate (docker_network, ip)
|
|
- Every outbound_connection id referenced by monitors/controllers exists
|
|
- Every sensor/actuator hil exists in hils
|
|
- Every HMI monitor/controller id exists as a register id on the target PLC (reachable via outbound_connection IP)
|
|
- Every HMI monitor/controller value_type and address match the target PLC register
|
|
Then output the fixed JSON object only.
|