/plc-code-analysis

name: plc-code-analysis
description: >
  Standalone skill for multi-perspective PLC code security and quality analysis.
  Triggers on: "review", "audit", "analyze", "security check", "vulnerability scan",
  "code review", "check this code", "is this safe", "find issues" when combined with
  PLC, SCL, ST, LAD, FBD, Structured Text, or block context. Also triggers when the user
  pastes PLC code and asks for feedback, or uploads exported SimaticML XML files.
  This skill is independent of tia-openness-roadmap — it does not perform engineering
  automation. It analyzes code that has already been exported, pasted, or is accessible
  via the TIA Portal MCP server.
license: MIT
disable-model-invocation: true

plc-code-analysis

Goal

Perform structured, multi-perspective security and quality analysis of PLC code, producing a severity-ranked findings report. Acts as an automated "second pair of eyes" for automation engineers.

Independence from tia-openness-roadmap

This skill is NOT routed by `tia-openness-roadmap`. It has its own trigger patterns and operates independently. The Openness roadmap handles engineering automation (create, modify, import/export via API). This skill handles analysis and review of existing code.

The skill can consume code retrieved through an integration or exported through Openness/VCI, but it does not depend on a particular wrapper.

Input recognition

PLC code commonly arrives in one of four ways. Identify the exact format and provenance before analysis.

Format 1 — Raw SCL / Structured Text

The user pastes or uploads `.scl`, `.st`, or plain-text PLC code. This is the simplest case. Parse directly as text. Look for FUNCTION_BLOCK, FUNCTION, ORGANIZATION_BLOCK, DATA_BLOCK headers to identify block boundaries.

Format 2 — SIMATIC SD source documents (V21)

TIA Portal V21 can export S7-1200/S7-1500 SCL, LAD, FBD, DB, F-DB, UDT, and F-UDT content in the text-based SIMATIC Source Document format. Analyze the `.s7dcl` declaration/code document together with its `.s7res` resources when both exist. Preserve document paths and identifiers so findings can be traced back.

SIMATIC SD is a source representation, not runtime evidence. In particular, an SCL block can be exported even when it is not compile-clean; successful export does not prove a successful compile, download, or PLC behavior.

Format 3 — SimaticML XML (exported LAD/FBD/SCL)

The user provides `.xml` files exported from TIA Portal. These follow the SimaticML schema. Key navigation points:

• `<SW.Blocks.FB>`, `<SW.Blocks.FC>`, `<SW.Blocks.OB>`, `<SW.Blocks.DB>` — block type
• `<Interface>` → `<Section Name="Input|Output|InOut|Static|Temp|Constant">` — variable declarations
• `<ObjectList>` → `<CompileUnit>` — individual networks
• `<FlgNet>` inside CompileUnit — LAD/FBD network logic as a directed graph
• `<Access>` elements — variable references with scope and UID
• `<Part>` elements — instructions (contacts, coils, function calls)
• `<Wire>` elements — connections between parts (data/signal flow)
• `<StructuredText>` — SCL compile-unit content, including inline SCL in LAD/FBD
• `<Comment>` — block and network comments (valuable for process context)
• Root block kind (`SW.Blocks.FB`, `SW.Blocks.FC`, `SW.Blocks.OB`, or

`SW.Blocks.GlobalDB`) and `<AttributeList>` elements such as `<Number>`, `<ProgrammingLanguage>`, and `<MemoryLayout>` (Optimized/Standard)

Validate XML against the installed V21 schemas rather than assuming a historical schema revision. The installed SCL schema is `SW.PlcBlocks.SCL_v4.xsd`; LAD/FBD and shared interface schemas are separate.

For LAD/FBD analysis, reconstruct the logic flow from the `<FlgNet>` graph: Parts are nodes, Wires are edges. Follow Powerrail → Contact chain → Coil/Function to understand each network's behavior.

Format 4 — MCP-assisted retrieval

If the TIA Portal MCP server is available, context retrieval is required before issuing security findings. Use the current Totally Integrated Claude MCP tools:

1. `browse_project_tree` — map PLCs, block folders, block names, and execution entry points 2. `get_block_content` — retrieve SIMATIC SD YAML for each block under review 3. `list_tag_tables` — retrieve PLC tags, user constants, and externally writable names 4. `read_cross_references` — inspect call paths, unused blocks, and variable references 5. `read_hardware_config` — retrieve CPU, network, IP, subnet, and interface settings 6. `compile_check` — record compile errors/warnings when the user asks for remediation

Legacy source documents may name equivalent operations as `GetBlocksWithHierarchy`, `ExportBlock`, `GetBlockInfo`, `GetTypes` / `GetTypeInfo`, or `GetHardwareConfig`. Treat those as conceptual aliases, not callable tool names.

If MCP is unavailable or a required context item cannot be retrieved, continue only as a limited review. The final report must include a context manifest and mark affected findings as inference-based where missing declarations, UDTs, call paths, tag tables, or hardware mapping prevent confirmation.

Analysis workflow

The analysis is performed in sequential passes. Each pass loads one reference file, analyzes the code through that specific lens, and produces findings.

**Critical instruction:** After each pass, Claude summarizes the findings from that pass in a compact internal list before loading the next reference. This prevents token pressure from accumulating raw analysis across all passes.

Pass order

| Pass | Reference file | Focus | |------|---------------|-------| | 1 | `references/process-architect.md` | Physical plausibility and process context | | 2 | `references/security-practices.md` | Top 20 Secure PLC Coding Practices + communication hardening | | 3 | `references/threat-mapping.md` | MITRE ATT&CK for ICS technique identification | | 4 | `references/compiler-critic.md` | Siemens platform bugs, CWE memory safety, safety boundary | | 5 | `references/hardware-reviewer.md` | Har