Customer challenge: A global beverage manufacturer has mixed Siemens and third-party equipment, inconsistent downtime data, and rising motor failures. It wants one scalable solution for line visibility and predictive maintenance, integrated with SCADA, MES and SAP, without disrupting production.
Stage 1 · Frame
Restate the problem before drawing
Show that you understand the outcome, constraints and decision to be made. Do not begin with products.
Say: “Let me confirm the business outcome, current environment and constraints. Then I’ll define measurable success and working scale, decide what to configure, extend or build, present the architecture, and close with testing and deployment.”
Business outcomes
The measurable value the architecture must deliver.
Why
Architecture constraints
Conditions that restrict the safe and supportable solution space.
Limits
Stage 2 · Discover
Ask questions that change the design
Group discovery into value, operations, technology, security and scale. If the panel withholds details, state safe, testable assumptions and mark them for validation. Never invent exact PLC brands, versions, tag counts or site facts.
Value and users
Which failure or delay costs the most?
Who acts on the insight, and within what time?
What baseline and target KPI define success?
OT and data
Which PLCs, drives, sensors and protocols exist?
Are vibration and temperature already captured?
What are the sampling, quality and retention needs?
Systems and ownership
Which SCADA, MES, historian, CMMS and SAP interfaces exist?
Which system owns asset, order and maintenance records?
Who supports the solution after handover?
Risk and scale
May the solution write to PLCs, or read only?
What zones, conduits, certificates and identities are required?
How many sites, assets, tags and messages at year three?
Say before making assumptions“Since those details are not available, I’ll proceed with conservative assumptions that protect production, safety, and future scalability. I’ll record them in an assumption log and validate them with the customer before finalizing the architecture.”
Working assumption log Safe · testable · provisional
Area
Best working assumption
Business value
Unplanned downtime is the main problem. Start with a critical production asset; measure reduced downtime and earlier fault detection.
Users
Operators need immediate alarms; maintenance needs diagnostics and predictions; engineering needs trends and root-cause evidence; management needs KPI summaries.
Response time
Safety and machine control remain real-time in the PLC. Operational alerts arrive within seconds; analytics may operate over seconds or minutes.
Existing OT
Assume a brownfield plant with mixed Siemens and third-party PLCs, drives, sensors and legacy serial devices. Exact assets require discovery.
Protocols
Reuse supported industrial protocols. Prefer OPC UA for structured machine data, gateways for Modbus RTU or serial equipment, and MQTT Sparkplug for scalable event distribution.
Condition data
Some vibration and temperature data is missing. Add nonintrusive sensors through an edge gateway without changing core control logic during the pilot.
Data collection
Sample at the rate required by the use case, aggregate at the edge, and send useful features and events upstream instead of uncontrolled raw data.
Existing systems
SCADA, MES, historian, CMMS and ERP are assumed to exist; their products, versions, interfaces and capacity require validation.
Portfolio strategy
Reuse or extend supported Siemens and customer capabilities through documented interfaces. Introduce a separate component only for a verified reusable gap. Installed products, versions, licenses, lifecycle status and roadmap alignment require validation.
System ownership
PLC owns control; SCADA owns supervision and alarms; MES owns execution; historian owns time-series history; CMMS owns maintenance; ERP/SAP owns orders and materials.
Source of truth
Each business object has one authoritative system. Other platforms reference it rather than creating competing master records.
Write access
Start read-only. AI, cloud and analytics do not write directly to PLCs. Future commands require an approved path, permissions, interlocks and operator oversight.
Security
Use IEC 62443-style zones and conduits, an industrial DMZ, certificate-based identities and least privilege. Controllers have no direct internet access.
Availability
Production continues when edge, MES, network or cloud services fail. Use store-and-forward buffering and graceful recovery.
Scale
Begin with one critical line and a limited tag set. Design namespaces, templates and deployment patterns for multiple lines and sites.
Support
Plant OT supports controls and field equipment; central IT supports infrastructure and identity; the product team supports applications, integrations and lifecycle updates.
Most important assumption to say aloud“I assume a brownfield, production-critical environment. Therefore, I will preserve deterministic PLC control, begin with read-only data acquisition, keep the plant operational during upstream failures, and design a secure edge-based integration that can scale from one line to multiple sites.”
If the panel changes an assumption“That new information changes the design. I would update the assumption, document the architectural impact, and reconsider the interface, security controls, availability requirement and deployment pattern before proceeding.”
Architect’s posture: The diagram is a working hypothesis tied to an assumption log, not a final design built on invented customer facts.
Stage 3 · Success and sizing
Define proof and working scale before selecting products
Convert the business problem into measurable acceptance criteria and explicit capacity variables. These are working assumptions, not invented customer facts.
Say: “Before choosing the solution, I will define the baseline, target, evidence source, measurement window and owner, then size the architecture against an agreed operating range with headroom.”
Working capacity model
Edit these variables when the panel supplies facts. The values below are examples for calculation practice only.
1,000nominal messages per second
1,300messages per second with headroom
2.03 Mb/sestimated payload rate
657.1 GBretention with headroom
Business acceptance
Baseline and target measure
Evidence source and operating window
Accountable business owner
Operator or maintenance action expected
Technical acceptance
Response time and data quality
Availability, RTO, RPO and offline duration
Peak load, retention and growth headroom
Security, recovery and upgrade evidence
Handoff: The agreed success measures and capacity range become the selection criteria for the configure, extend or build decision.
Stage 4 · Decide
Enhance the portfolio or build a component?
Use explicit criteria. Avoid rebuilding a capability Siemens or the customer already operates well.
Extend existing capabilities
Enhance a supported Siemens or customer platform through configuration, approved extensions, applications or documented interfaces. Prefer this when the required capability is common, already close to the product’s purpose and can remain inside its supported lifecycle.
OR
Build a new component
Create a separate, reusable service only when there is a verified capability gap or differentiating need that existing products cannot meet cleanly. Keep it loosely coupled so the new component does not become an undocumented dependency inside PLC, SCADA or MES.
Select a decision factor
Choose one of the four controls above to explain its architectural meaning, evidence and tradeoff.
Extend when
The portfolio already covers most of the use case.
Configuration or an approved extension can close the gap.
The vendor’s security, monitoring and upgrade mechanisms remain usable.
The feature benefits other customers and fits the product roadmap.
Build when
The gap is verified and materially differentiates the solution.
The component can be reused across assets, lines or sites.
A team owns funding, security, support, testing and retirement.
Versioned APIs isolate it from Siemens and customer product upgrades.
Avoid extending when
It requires unsupported modification of product internals.
Every upgrade would overwrite or break the customization.
It mixes AI or business logic into deterministic PLC control.
The product becomes responsible for data it does not own.
Avoid building when
A supported portfolio feature already solves the requirement.
The solution is a one-site script without a lifecycle owner.
The interface depends on private databases or internal product tables.
The long-term support cost exceeds the customer value.
Decision rule: Extend when the need is common and product-aligned. Build when the capability is differentiating, reusable, loosely coupled and has a funded lifecycle owner.
Stage 5 · Architect
Overlay function, placement and security
Draw the production stack bottom-up, then explain demand top-down and evidence upward. Keep the three frameworks distinct.
ISA-95 · responsibility
Defines what enterprise, operations, supervision and control functions do, who owns the information and what crosses each interface.
Purdue · placement
Provides a practical level-based view of where industrial systems and network services are commonly placed.
IEC 62443 · enforcement
Defines risk-based zones, conduits, identities and security requirements. These controls protect connections within and between levels.
Say: “ISA-95 tells me what each system does, Purdue helps me position it, and IEC 62443 tells me how to secure the connections.”
Level 4 Enterprise
Level 3.5 Industrial DMZ
Level 3 Operations
Security conduit Not a Purdue level
Level 2 Supervision
Level 1 Control
Level 0 Process
Interactive board: Select any component to explain its responsibility and boundary.
Control relationship: PLC sends the operating command → drive regulates motor speed or torque → motor performs the physical work. The drive returns operating status and diagnostics to the PLC. Pairing the PLC and drive at Level 1 shows their control relationship; it does not mean they perform the same function.
PLC ↔ remote I/O and drives: PROFINET for Siemens equipment; EtherNet/IP where supported by other control platforms.
PLC ↔ HMI: Supported Siemens S7 communication or OPC UA, selected by compatibility and security needs.
PLC → SCADA and edge: OPC UA for structured values, timestamps, quality and governed subscriptions.
MES, CMMS and ERP: REST, OData or supported product APIs for governed business transactions.
Legacy serial equipment: Modbus RTU or vendor protocol through an approved industrial gateway.
Security structure · draw vertically
Put the Industrial DMZ between enterprise Level 4 and operations Level 3.
Add cell-area enforcement between operations and lower control zones.
Permit only required conduits, ports, identities and data directions.
Use certificates, least privilege, managed secrets and approved remote access.
Scalability structure · draw horizontally
Use an ISA-95 namespace and reusable equipment templates.
Decouple sources and consumers through edge services and messaging.
Size tag volume, message rate, storage, compute and network headroom.
Standardize site configuration, fleet monitoring, upgrades and support ownership.
Where to discuss them: Capture security and scale requirements during discovery, show both structures on the architecture, verify them through security and load testing, and operationalize them in the deployment template.
Siemens portfolio fit
Fit current needs to a future Industry 4.0 path
Map requirements to supported Siemens capabilities before proposing custom software. This is a candidate portfolio, not a final bill of materials.
Product decision aid
Present foundation and future scale
Select a Siemens product family to explain the current purpose, future value, architecture boundary and extend-or-build decision.
Select a product
Architect’s caution: SAP is an enterprise system to integrate, not a Siemens product selection. Product editions, installed versions, licenses, interfaces, cloud policy and Siemens roadmap alignment must be confirmed during discovery.
Say: “I will reuse supported Siemens capabilities where they fit, protect the customer’s installed investment, and build only a verified reusable gap behind a stable API and clear lifecycle owner.”
Stage 6 · Integrate
Choose interfaces by behavior
Protocols are complementary. Label each arrow with purpose, direction, ownership, timing and security.
Need
Choice
Architect’s reason
PLC to Siemens I/O and drives
PROFINET
Cyclic, time-sensitive control remains inside the control zone. Use EtherNet/IP where a supported third-party control platform requires it.
PLC to HMI
S7 communication or OPC UA
Use the supported Siemens HMI path for operation; choose OPC UA where openness, security and structured interoperability are required.
PLC to SCADA or edge
OPC UA
Structured values, subscriptions, timestamps, quality and certificate-based security without placing enterprise latency in the control loop.
Edge to broker and consumers
MQTT Sparkplug
Decoupled publish-subscribe, state awareness, buffering and efficient site distribution.
Orders, materials and work orders
REST / OData API
Transactional request-response with business validation and clear system ownership.
Brownfield serial devices
Gateway
Convert approved RS-232/485 or Modbus RTU data without invasive controller changes.
New edge connector or data service
Rust, when justified
Memory-safe, high-performance implementation for concurrent acquisition, validation, buffering and publishing. Rust is a language, not a protocol.
Say: “I use PROFINET or EtherNet/IP for time-sensitive machine control, OPC UA for structured supervisory data, MQTT for scalable event distribution and APIs for business transactions.”
Rust is ideal when
Building a new, long-running edge service or protocol adapter.
Memory safety and concurrent data pipelines are important.
Required OPC UA, MQTT and device libraries are supported.
The team can build, test, patch and support Rust throughout its lifecycle.
Do not force Rust when
Programming Siemens PLC logic; use LAD, FBD or SCL.
A vendor SDK is available only in C or C++.
An existing supported Siemens component already provides the capability.
The support team lacks a sustainable Rust toolchain and ownership model.
Architect’s answer: “Rust can be an excellent implementation choice for a new edge component, but I would select it only after confirming portfolio fit, libraries, team capability, support ownership and lifecycle cost.”
Stage 7 · Test
Prove function, security, scale and recovery
Testing begins after each component and interface is built. FAT must pass before site release; SAT and operational acceptance follow deployment.
Select a test area to see the procedure. Check it only after the displayed pass condition is met.
Requirements traceability: each use case has a measurable acceptance criterion and owner.
Unit and data tests: functions, mappings, units, timestamps, quality and asset context are correct.
Interface integration: schemas, versions, authentication, timeouts, retries and duplicate handling are tested.
Resilience: PLC autonomy, disconnect, buffering, restart, failover, reconciliation and rollback are demonstrated.
Security: zones, conduits, least privilege, certificates, secrets, logging and patch process are verified.
Scalability: tag count, message rate, latency, storage, CPU, memory and growth headroom are load tested.
AI assurance: baseline, precision, recall, false alarms, drift, explainability and human approval are verified.
Acceptance gates: FAT authorizes site release; SAT, training, runbook and handover authorize operation.
Requirement-to-evidence traceability · select a use case
Test sequence: unit test → interface test → integration and failure test → security and load test → FAT → controlled deployment → SAT → operational acceptance.
Stage 8 · Deploy
Move from validated pilot to global operation
Deploy only after the relevant test gate passes. Use controlled waves, clear rollback and an operating model that scales across sites.
1 · Reference pilot
One representative motor and line. Start read-only; establish the baseline, asset model, KPI and operator workflow.
2 · Controlled site release
After FAT, deploy in an approved window with backups, certificates, configuration, monitoring and a tested rollback plan.
3 · SAT and handover
Verify the real PLC-to-edge-to-application flow, failure recovery, security controls, user workflow, runbooks and support ownership.
4 · Scale globally
Use parameterized site templates, wave deployment, readiness gates, automated provisioning, central governance and fleet health.
Operating ownership
PLCDeterministic control, permissives, interlocks and safety boundaries.
DriveMotor regulation, operating state and electrical diagnostics.
HMI / SCADASupervision, alarms, trends and approved operator commands.
EdgeConnectivity, normalization, buffering and local analytics.
BrokerEvent distribution; it is not a firewall or system of record.
HistorianTime-series evidence, retention and operational history.
MESProduction execution, genealogy and manufacturing workflow.
CMMSMaintenance work orders, priorities and closure records.
ERP / SAPOrders, materials, cost and business master records.
Product teamApplication, integrations, security updates, support and retirement.
Non-negotiable: Loss of MES, edge, MQTT or cloud must not stop the PLC-controlled production process.
Stage 9 · Close
Summarize the design in 90 seconds
Close on the decision, boundaries, delivery path and measurable value. Then invite challenge.
Model closing response
“I would first validate the business problem, users, success measures and existing environment. Where details are unavailable, I would document conservative assumptions and begin with a read-only pilot on one critical asset.”
“ISA-95 defines the system responsibilities, Purdue helps place them and IEC 62443 secures the connections. Deterministic control and safety remain in the PLC. PROFINET supports time-sensitive Siemens control, OPC UA carries structured machine information, MQTT distributes contextualized events and APIs integrate MES, CMMS and ERP transactions.”
“I would reuse supported Siemens capabilities and build only a verified reusable gap with stable APIs, clear ownership and an upgrade path. The Industrial DMZ controls enterprise-to-operations exchange, while cell-area controls protect lower levels. We would prove data quality, recovery, security, AI performance and scale before FAT, controlled deployment, SAT and handover. Production would continue if edge, MES, broker, network or cloud services failed.”