Implementing a process analyzer that is not integrated with the control layer ends the same way — the operator looks at a separate screen, and the data never reaches the quality reports. At Gekko Photonics, we design and manufacture process Raman analyzers in Poland, in inline, laboratory, and portable variants, and for each implementation, integration with DCS, MES, and SCADA is a separate work stream — not an annex to the equipment delivery. This article organizes how these three layers differ from the analyzer's perspective, which protocols make sense, where the IT/OT boundary lies, and what a realistic acceptance checklist looks like.

DCS, MES, SCADA — what we integrate and with what

From the perspective of a process analyzer, the three automation layers serve different roles and require different data:

• DCS (Distributed Control System) — the real-time control layer (seconds). Measurement results treated like any other process variable (e.g., „free formaldehyde in reactor, wt%”) are sent here, along with measurement quality flags. The DCS is to decide whether the process is proceeding as intended and when to end a batch.
• SCADA (Supervisory Control and Data Acquisition) — the visualization and trend archiving layer. The operator sees the result curve over time, alarms, and device status. SCADA is very often what the operator sees „alongside the DCS,” and in smaller installations, it simultaneously serves as the DCS.
• MES (Manufacturing Execution System) — the production execution layer: batch number, operation sequence, recipe parameters, compliance report. Analyzer results arrive here in aggregated form, within the batch context — not raw spectra, but e.g., „final biuret content,” „end-point criterion met.”.

A good integration project consciously separates these three streams. The same data source (analyzer and its chemometric model) feeds all three layers, but with different granularity, different time SLA, and different format.

Protocols — what we actually encounter in Polish and European installations

At the fieldbus/control layer, two dominant families are encountered today:

• PROFIBUS DP / PROFINET — dominant in European installations, especially in the chemical industry and petrochemistry designed based on Siemens. PROFIBUS remains present in older installations; PROFINET (industrial Ethernet) is replacing it in new projects.
• Modbus RTU / TCP — a low-level integration, proven as a universal bridge between a field device and a third-party controller. Cheap, simple, semantically limited.
• OPC UA — the de facto standard for MES ↔ DCS integration and for IT/OT scenarios. It carries semantics (Information Model), security (certificates, signing & encryption), and is the foundation for architectures compliant with NAMUR Open Architecture.
• Ethernet/IP — dominant in American installations based on Rockwell/Allen-Bradley; encountered less frequently in the Polish chemical industry.

From our practice: the analyzer delivers results within several to several tens of seconds, so there is no need to chase hard DCS time loops. PROFINET or OPC UA via a gateway cover most cases. The MES layer is almost always OPC UA or REST API — from an integration gateway in the OT layer.

IT/OT boundary — where to place it

The process analyzer resides in the OT (operational technology) layer — on the production floor, connected to automation. Quality data and batch reports must, however, reach the MES, data warehouse, and BI tools in the IT layer. The boundary must be conscious:

• OT Zone — analyzer, its computing unit with chemometric models, PLC/DCS controller. Communication via fieldbus or dedicated industrial Ethernet in a control VLAN.
• Industrial DMZ Zone — integration gateway (OPC UA Server, historian connector, REST gateway). Access from the IT layer ends here; data is signed and versioned.
• IT Zone — MES, ERP, data analytics tools. Access only to the gateway in the DMZ, never directly to the analyzer.

Practical consequence: if the IT team wants „access to Raman spectra” for training predictive models, this access is realized through an export from the gateway — with RBAC control, audit trail, and a mock of production traffic. Not by directly plugging into the control network.

Integration checklist — from workshop to acceptance

Each analyzer implementation in a DCS/MES/SCADA environment goes through the same structure at our company:

1. Integration Workshop (1 day) — with participation from the maintenance, automation, IT teams, and the process owner. We establish: which variables go to DCS, which to SCADA, which aggregates to MES, physical protocols, IP addresses, VLAN, firewall policies.
2. Interface Specification — a variable list document: name, type, unit, update frequency, quality flags, mapping to registers / OPC UA NodeId. Signed by both parties.
3. FAT (Factory Acceptance Test) — at Gekko Photonics, we test the analyzer's communication with a simulated controller or with a physical test controller provided by the client. We check each variable from the list, the alarm path, and behavior during communication loss.
4. SAT (Site Acceptance Test) — after delivery to the line. Here we test the real chain: analyzer → gateway → DCS → SCADA → MES, on the actual process with reference samples.
5. Chemometric Model Validation — a separate stream. Analyzer results must be consistent with the reference laboratory method (e.g., titration, HPLC). Here we typically measure RMSECV typically below 0.2 wt% for calibration ranges of 0.1–5 wt%, depending on the analyte and matrix.
6. Service Procedure — who responds to the alarm „no data from the analyzer,” what the re-calibration process looks like, who has the authorization to Spectrally OS, how we archive spectra.

Most common integration errors

• Lack of measurement quality flags — the analyzer sends a value but does not send a „low-quality data, e.g., dirty probe, model out of range” flag. Without this, the operator does not know when to trust the number and when to hold a decision.
• Layer confusion — raw spectra sent to MES (gigabytes of useless recording) or aggregated batch reports flooding the DCS (slowing reaction time).
• Lack of time sync path — the analyzer and controller have different clocks, drifts appear in trends. NTP in the control layer is an absolute must.
• Directly opening the analyzer to the IT network — a security mistake that only disappears after the first cybersecurity audit. Everything goes through a gateway in the DMZ.
• Undefined service SLA — who responds, within what time, to an incident „analyzer not publishing data to DCS.” Without this, maintenance is left alone with a device they do not know.

Gekko Photonics solutions — integration of Spectrally X1 with DCS, MES, and SCADA

Our Spectrally X1 INLINE natively supports PROFIBUS, PROFINET, and GSM (for alarming and remote diagnostics). This covers most European chemical installations. Where OPC UA, Modbus TCP, or Ethernet/IP is needed, we implement integration via a gateway in the OT layer — from the native control protocol to the one expected by the client's DCS/SCADA.

Software layer Spectrally OS manages spectrum acquisition, chemometric models (CNN, PLS, PCA), and raw spectrum archiving. It exports results in CSV, PDF, and RAW formats, offers role-based access control, and runs on Debian GNU/Linux 13.2 — which simplifies cybersecurity audits and certification for pharmaceutical or food industry clients. Dashboards in SpectrallyUI provide the operator in the SCADA layer with spectrum and trend charts without needing to build them from scratch in the higher-level system.

For laboratory scenarios — model validation, raw material verification, IQC — we connect the X1 INLINE with Spectrally X1 LAB as a shared chemometric ecosystem. Models built in the laboratory are transferred to production without rewriting from scratch.

The complete offer of our analyzers — with a list of variants and configurations — is available on the website /analyzers/. For industry-specific details — phenolic-formaldehyde resins, fertilizers, cosmetics, hydrocarbons — we invite you to knowledge base, where we publish subsequent posts on Raman spectroscopy in specific applications.

FAQ — frequently asked questions

Does the Spectrally X1 INLINE communicate natively via OPC UA?

The analyzer natively offers PROFIBUS, PROFINET, and GSM. We implement OPC UA through an integration gateway at the OT layer — this preserves control separation and maintains OPC UA semantics (Information Model, certificates, signing and encryption) without compromising cybersecurity.

How long does a typical integration of the analyzer with a DCS take?

The communication integration itself — from workshop to SAT — typically takes 2–6 weeks, depending on the availability of the client's teams and the maturity of the DCS documentation. Full analyzer deployment (including chemometric model validation and service procedures) typically takes 3–5.5 months at our end.

Do we need to purchase the OPC UA gateway separately?

Depending on the project, we supply the gateway as part of the deployment package or integrate into the client's existing gateway (if the plant already has a DMZ layer). The decision is made during the integration workshop, based on the OT network architecture.

How does Gekko Photonics handle cybersecurity audits?

Spectrally OS is built on Debian GNU/Linux 13.2 with a security update policy, role-based access control, and a full audit trail. For clients in pharmaceuticals, food & beverage, and regulated sectors, we provide documentation: architecture description, port list, hardening guidelines, and mapping to IEC 62443. Cybersecurity audits are conducted together with the client's IT team during the workshop and prior to acceptance.

Do the Raman spectra remain in the OT layer or go to a data warehouse?

This is a design decision. By default, raw spectra are archived locally in Spectrally OS (due to volume — typically gigabytes per month). Aggregated results, quality flags, and batch metadata are sent to the MES and data warehouse. Export of raw spectra to the IT data warehouse is performed on demand, in batch mode, via the OPC UA gateway or REST from the DMZ.

Test measurement and engineering consultation

Each deployment begins with a conversation with your automation and IT team — a 30-minute engineering consultation is sufficient to determine whether the Raman analyzer makes sense in your DCS/MES/SCADA architecture, which protocols are actually needed, and where to place the IT/OT boundary. After that, we propose a test measurement on your samples in our laboratory within 2 weeks — this confirms that Raman is the right method for your analyte and matrix before you enter the CAPEX phase. Contact us — we will send the variable list template for the integration workshop and propose a date.