| name | pharaoh-deployment-diagram-draft |
| description | Use when drafting one deployment diagram showing physical nodes (ECUs, servers, boards), the software artefacts deployed on each, and communication channels (buses, networks). Typical ASPICE usage — SYS.3 System Architectural Design; essential for automotive HW/SW allocation per ISO 26262 Part 5 (HW) and Part 6 (SW). Renderer tailored via `pharaoh.toml`. Status — PLANNED (design-only scaffold; invoking returns sentinel FAIL until implemented). |
pharaoh-deployment-diagram-draft (PLANNED)
Status: DESIGN ONLY. Implementation sentinel FAIL: "pharaoh-deployment-diagram-draft is planned but not implemented; see SKILL.md".
Shared tailoring rules: see shared/diagram-tailoring.md. Reads [pharaoh.diagrams.deployment].
Safe-label rules: see shared/diagram-safe-labels.md. Every emitted label / node id / edge label MUST be sanitised per that rule set before the block leaves this skill. sphinx-build does not validate diagram bodies — a parse failure becomes visible only at browser render time. Sanitisation is the first line of defence; the second is pharaoh-diagram-lint run as part of pharaoh-quality-gate.
Purpose
One invocation → one deployment diagram. Captures execution environment topology: physical/virtual nodes, the software artefacts (components, containers, services) deployed on each, and the communication channels between nodes (CAN bus, Ethernet, IPC, HTTP, etc.).
Typical ASPICE / ISO 26262 context:
- SYS.3 System Architectural Design: allocation of system elements to HW.
- ISO 26262 Part 5 (Hardware level): mapping safety goals to HW elements.
- ISO 26262 Part 6 (Software level): SW partitioning across ECUs with ASIL tagging.
Atomicity
-
(a) One deployment topology in → one diagram out.
-
(b) Input: {view_title: str, nodes: list[NodeSpec], artefacts: list[ArtefactSpec], deployments: list[DeploymentSpec], channels: list[ChannelSpec], project_root: str, renderer_override?, on_missing_config?, papyrus_workspace?, reporter_id: str} where NodeSpec = {id: str, label: str, kind?: "device"|"ecu"|"server"|"cloud"|"container", stereotype?: str, asil?: "A"|"B"|"C"|"D"|"QM"}, ArtefactSpec = {id: str, label: str, kind?: "component"|"container"|"library"|"binary"|"config"}, DeploymentSpec = {node: str, artefact: str}, ChannelSpec = {from: str, to: str, label?: str, protocol?: str}. Output: one RST directive block.
-
(c) Reward: fixture — two ECUs (ECU_A ASIL B, ECU_B ASIL D), three artefacts, deployments mapping artefacts to ECUs, CAN bus channel between them. Scorer:
- Output starts with renderer directive.
- Every node rendered with cube/node shape.
- Every artefact rendered inside its deployed node.
- Every channel rendered with labeled arrow and protocol annotation.
- ASIL tag (when present) visible on node label or as stereotype.
- Deployment without a matching node/artefact → FAIL (dangling deployment).
Pass = all 6.
-
(d) Reusable across embedded / distributed / cloud projects; not automotive-specific (ASIL tag is optional).
-
(e) One diagram per call.
Dangling relationships
FAIL on deployments.node not in nodes, deployments.artefact not in artefacts, channels.from/channels.to not in nodes.
Output
PlantUML (richest deployment syntax):
.. uml::
:caption: <view_title>
@startuml
node "ECU_A\n<<ASIL B>>" as ecuA {
artifact "sensor_driver" as art1
artifact "can_stack" as art2
}
node "ECU_B\n<<ASIL D>>" as ecuB {
artifact "brake_controller" as art3
}
ecuA ..> ecuB : CAN (500kbit/s)
@enduml
Mermaid:
.. mermaid::
:caption: <view_title>
flowchart LR
subgraph ECU_A["ECU_A (ASIL B)"]
art1[sensor_driver]
art2[can_stack]
end
subgraph ECU_B["ECU_B (ASIL D)"]
art3[brake_controller]
end
ECU_A -.CAN 500kbit/s.-> ECU_B
Non-goals
- No electrical schematic — use dedicated EE tools for that.
- No real-time timing analysis on channels — a separate
pharaoh-timing-diagram-draft could cover message schedules.
- No auto-derivation from HW description files (e.g. ARXML) — caller provides explicit node and deployment specs.
