The phrase "integration project" triggers a specific kind of dread in Japanese manufacturing IT. It implies months of scoping, a systems integrator quote in the tens of millions of yen, extended testing periods, and then ongoing maintenance costs that outlast the original business case. For a mid-size facility with a two-person IT team and a plant manager who needs OEE data this quarter, the traditional integration project model is not a practical option.
The good news is that connecting PLC data to modern analytics no longer requires that kind of project. The bad news is that "connecting" without understanding the protocol stack usually produces data that looks correct but is not — a problem that only surfaces three months later when someone notices the OEE numbers diverging from shift reports.
Understanding What Your PLC Actually Speaks
Before choosing a collection method, you need to know which protocol your PLCs support. This sounds obvious but is frequently skipped, leading to wasted gateway configuration time. The answer is not always in the manual — it sometimes requires a conversation with the OEM or a network scan.
The most common protocol landscape in Japanese mid-size factories breaks down roughly as follows. Mitsubishi MELSEC Q-series and iQ-R series controllers support MC Protocol (also called MELSEC Communication Protocol or 3E frame) natively over Ethernet, and most also support OPC-UA via an add-on communication module or the iQ Works software suite. FANUC CNCs running the iSeries (0i, 30i, 31i, 32i) expose data via FANUC FOCAS2 — a proprietary library, not an open standard — unless the optional MTConnect adapter or an OPC-UA server module has been added. Omron Sysmac NJ/NX controllers support OPC-UA natively as of firmware 1.10 (circa 2018); older NS-series and CJ-series units rely on FINS protocol over Ethernet or serial. Yaskawa MP3000 and Sigma-7 drive systems typically communicate via MECHATROLINK-III at the motion level, with Ethernet/IP or Modbus TCP available for supervisory data collection.
Two broader standards are worth understanding as integration targets rather than native PLC protocols: OPC-UA (IEC 62541), the current de facto standard for machine-to-system communication in industrial automation; and Modbus TCP, the older but still widely deployed open standard that almost every PLC supports as a secondary interface. MTConnect is specifically relevant for CNC machine tools and is worth considering if your facility has a significant machining operation.
OPC-UA: The Right Long-Term Choice with Real Short-Term Caveats
OPC-UA is the right architectural choice for any new connectivity you are building today. It is a mature, vendor-neutral standard with a well-defined security model (certificate-based authentication, encrypted transport), a self-describing information model (the OPC-UA address space), and growing native support in modern PLCs. For greenfield lines or recently procured equipment, OPC-UA should be the default protocol target.
However, we are not saying OPC-UA makes PLC connectivity simple. There are three common failure modes that we see in mid-size factory deployments.
The first is OPC-UA server misconfiguration on the PLC side. Mitsubishi's OPC-UA module for the Q-series, for example, requires explicit node configuration — you do not automatically get all data tags exposed; you must define the information model in advance. A common error is connecting to the OPC-UA server and finding only a handful of nodes, then concluding the PLC data is not accessible. The data is there, but the address space was never configured. This is a setup task for a controls engineer, not a software configuration wizard.
The second failure mode is timestamp handling. OPC-UA provides source timestamps (when the PLC sampled the value) and server timestamps (when the OPC-UA server recorded it). For OEE cycle time calculation, you need source timestamps. Many off-the-shelf OPC-UA clients default to server timestamps without making this configurable. In a factory with a 1-second PLC scan cycle and a network hop between PLC and server, the difference can be 100-300ms — irrelevant for most monitoring but significant if you are calculating cycle times on short-duration operations.
The third failure mode is security model friction. OPC-UA's certificate-based security is an asset in the long run but requires a factory to manage PKI infrastructure, which most mid-size facilities are not equipped for. In practice, many deployments run in "No Security" mode during pilot and then face a retroactive hardening project. Better to configure signed certificates from day one — the setup cost is a few hours, and the operational cost is an annual certificate renewal.
Modbus TCP: The Pragmatic Fallback
For equipment that does not support OPC-UA natively, Modbus TCP is typically available and often the fastest path to initial data collection. Virtually every PLC, VFD, and smart sensor manufactured in the last 20 years supports Modbus registers. The protocol is simple, well-documented, and requires no special licensing or server configuration.
The limitations are real and should be understood upfront. Modbus has no built-in security — it assumes a trusted network. It has no self-describing data model — you need the PLC register map from the controls engineer or OEM, and these documents are often incomplete or outdated. It polls rather than pushes, which means your collection frequency is limited by the polling interval and the number of registers you can read in a single request.
For collecting 20-30 data points from a single PLC at 1-second intervals — cycle counts, fault codes, setpoint vs. actual comparisons — Modbus TCP works well. For collecting 200+ tags across 15 PLCs with millisecond-level timing requirements, you will hit its limits quickly.
Consider a precision parts facility in Niigata running 8 Yaskawa MP3000 controllers on a machining line. The MP3000 supports both Modbus TCP and MECHATROLINK-III. For supervisory OEE data — production counts, fault status, shift mode — Modbus TCP polling at 5-second intervals from a lightweight edge agent was sufficient and took three hours to configure. For spindle load and axis position data needed for predictive maintenance, a separate motion analytics path via MECHATROLINK would be appropriate, but that was scoped as a Phase 2 project.
Edge Agent Architecture vs. Direct Cloud Polling
The question of where to do the collection work — on an edge device at the factory or by polling directly from cloud infrastructure — is consequential for real-time OEE applications.
Direct cloud polling introduces network latency as a variable. For factories with reliable on-premise LAN and well-behaved PLCs, the round-trip from PLC to cloud and back can be acceptable for 5-second or 30-second data granularity. For 1-second cycle time data on a line with 3-second actual cycle times, any cloud-polling architecture will introduce jitter that makes the numbers untrustworthy.
An edge agent — a lightweight process running on a small industrial PC on the factory LAN — collects data locally at full PLC speed, buffers it, and synchronizes to the cloud on a tolerant schedule. This architecture also handles the most common real-world problem: intermittent network connectivity. Factory networks go down for maintenance windows, VPN tunnels reset, and internet links fail during typhoon season. An edge agent with local buffering continues collecting data through network interruptions and reconciles the gaps when connectivity restores. A direct-cloud architecture either loses data during the outage or requires complex reconnection logic that most IT teams do not have time to build and maintain.
The trade-off is operational complexity: you are now managing an edge device in the factory, which requires firmware updates, physical access, and integration with the factory's network security policies. For most mid-size Japanese facilities, this is a manageable trade-off — one small industrial PC per production area is not a significant operational burden, and the data quality benefit is tangible.
Practical Starting Points by PLC Type
If you are scoping a first connectivity project, here is a practical starting frame:
For Mitsubishi MELSEC iQ-R (2017 and newer): use OPC-UA with the built-in server module. Configure 20-40 key tags in the address space. Aim for source timestamps. Plan for certificate management from day one.
For Mitsubishi MELSEC Q-series (pre-2017, still very common): use MC Protocol via Ethernet if OPC-UA module is not installed. Libraries are available for most common languages. Alternatively, a MELSEC-to-OPC-UA gateway appliance avoids custom code.
For FANUC CNCs (iSeries): FOCAS2 is the path unless an OPC-UA server module is installed. The FOCAS2 library gives access to program execution status, alarm codes, axis load, and spindle speed — enough for OEE and basic anomaly detection. MTConnect adapter is available as a FANUC add-on for customers who prefer a standard output.
For Omron Sysmac NJ/NX (2018+): OPC-UA native. For older CJ-series: FINS via UDP, or a CJ-to-OPC-UA gateway.
For Yaskawa MP3000: Modbus TCP for supervisory data is the simplest path. EtherNet/IP is available and better if you are building a larger integration.
None of these paths require a systems integrator engagement for an initial pilot scope of one or two lines. They do require a controls engineer who knows the specific PLC firmware version and network configuration — which is why the first step in any connectivity project is a 2-hour 現場 (genba) walkthrough with whoever maintains the PLCs, not a project charter from the IT department.