Which spare interfaces and utilities should be provided for future automation ART-164

Start with the scenario, not the protocol

“We need OPC UA” is not a technical specification. First describe exactly what must happen between the equipment. Each scenario needs an initiator, enabling conditions, commands, acknowledgments, status data, error response, and safe state.

Typical future laser work-area scenarios:

• a loader supplies a sheet and receives permission to enter the work zone;
• an unloader removes the skeleton and parts after program completion;
• tower storage delivers material with a confirmed format, grade, and thickness;
• CAM or MES sends a job and the machine returns the actual result;
• a monitoring system reads states, alarms, cutting time, and downtime;
• marking or traceability links the sheet, program, batch, and finished parts;
• an external system receives maintenance-needed data but does not control hazardous motion;
• a robot or conveyor exchanges handshake signals with the cell.

For every scenario, separate three exchange classes: control, status and diagnostics, and production data. Their requirements differ. What is convenient for analytics is not necessarily suitable for real-time coordination or a safety function.

Five levels of readiness

| Level | What is reserved | Required evidence | |---|---|---| | Physical | space, cable routes, cabinet, attachment points, aisles | layout and agreed envelopes | | Electrical | power, protection, PE, spare terminals, isolated I/O | diagram, ratings, spare list | | Control | commands, permissions, states, fault/reset logic | signal matrix and sequence diagram | | Data | tags, context, timestamps, identifiers, quality | data dictionary and sample payload | | Organizational | change owner, backup, licenses, acceptance | RACI, change process, contract annex |

A weak project often has only the first level: space has been left beside the machine. A robust project has an agreed path from physical connection to a verified acceptance scenario.

Discrete I/O: simple but not primitive

Discrete inputs and outputs remain useful for clear handshakes: “ready,” “permission,” “cycle complete,” “material in position,” and “cell fault.” Their advantage is simple diagnostics and a clear boundary. Their limitation is a restricted number of states and the risk of ambiguous logic.

Before procurement, agree:

• available voltage and signal type;
• sourcing/sinking or relay contact, isolation, and common reference;
• permitted current and protection method;
• default state after controller restart;
• response to a broken wire and power loss;
• whether pulse/edge signals or a maintained state are required;
• debounce, timeout, and sequence reset;
• separation of operational and safety I/O;
• the number of genuinely free channels after the basic configuration;
• terminal location, marking, and cabinet reserve.

A channel cannot be called “spare” if it is already needed for an option, is not brought out to a terminal, is blocked by manufacturer logic, or needs an unknown expansion module. Request an I/O list for the current configuration and a separate table of channels available for third-party integration.

A safety interface cannot be replaced by an ordinary signal

Motion permission, doors, a light curtain, robot zone, emergency stop, and safe stop may belong to a safety-related control system. An ordinary PLC bit or message through a data API does not become a safety function merely because it is named `SAFE_OK`.

Before future integration, establish:

• which safety functions the machine already implements;
• whether a certified interface for an external cell is provided;
• which PL/SIL or other requirements the risk assessment specifies;
• who is responsible for the changed machine and cell boundary;
• whether the manufacturer permits additional guard devices;
• how validation is performed after modification;
• what happens on communication loss or channel discrepancy.

A competent integrator selects components, wiring, and validation under current standards and manufacturer instructions. There is no universal arrangement for all lasers.

Industrial Ethernet: reserve the architecture, not a free port

One unused RJ45 on the controller does not solve future integration. Clarify its purpose, supported protocols, licensing, network ownership, and security boundary. Some ports may be only for manufacturer service, the internal machine network, or HMI.

Practical provisions include:

• a separate managed switch for production integration;
• marked cable routes separated from power lines;
• spare switch ports and bandwidth reserve;
• industrial connectors where the environment requires them;
• a defined VLAN/zone and firewall boundary;
• a MAC/IP/device-identity inventory;
• an agreed time method—NTP/PTP only as required by the scenario;
• a test point that does not require connecting a random laptop to the control network;
• addressing, port, and allowed-flow documentation;
• a change owner and configuration log.

NIST SP 800-82 Rev. 3 emphasizes that OT systems have specific performance, reliability, and safety requirements. Do not copy a corporate IT template without assessing its effect on the control system. Detailed remote support belongs to ART-163; here, the important point is not to create a future bypass of that architecture.

OPC UA: an exchange framework, not automatic compatibility

The OPC Foundation describes OPC UA as infrastructure for interoperable exchange from machine-to-machine communication to enterprise integration. Importantly, OPC UA is not just transport: it supports information models, security, discovery, and different profiles. However, two products labeled OPC UA may have different information models, supported services, and security policies.

The specification therefore needs more than “OPC UA available”:

• the server or client role of each party;
• exact version and supported profiles;
• namespace and companion specification, if applicable;
• nodes, methods, events, and alarms;
• read/write permissions;
• certificate lifecycle and trust-list ownership;
• user authentication and role mapping;
• subscription limits, sampling, and publishing interval;
• timestamp source and quality/status codes;
• behavior after reconnect;
• the license included in the supply;
• a test endpoint or information-model export.

If the future scenario is only collecting indicators, a read-only server may be sufficient. Job transfer or machine coordination needs other methods, a state model, and acceptance tests. Do not order write access “just in case” without a defined need: it expands the risk surface.

MTConnect: strong data semantics do not equal machine control

The MTConnect Institute defines MTConnect as an open, royalty-free standard for accessing structured manufacturing-equipment data. Part 1.0 describes equipment, an agent, and a client application, along with semantic models for observations and assets. This is useful for status monitoring, OEE inputs, alarms, program context, and comparison of different machines.

The standard nevertheless has a defined scope. If a coordination or interaction model is needed, check the supported part of the standard and the manufacturer's implementation. MTConnect in a brochure does not guarantee the full set of required data items.

Request sample `/probe`, `/current`, or equivalent responses, agent version, asset list, frequency/retention behavior, and mapping of machine-native states. Separately verify whether the data represents actual state or merely HMI labels.

Production data: identifiers matter more than a large stream of tags

Future automation stalls not because temperature tags are missing, but because stable identifiers are absent. The data contract should provide for:

• machine ID and cell ID;
• order, job, program, and revision ID;
• material batch and sheet ID;
• part/nest ID;
• operator or shift context under enterprise policy;
• planned quantity, completed quantity, scrap/rework state;
• start/end timestamps and reason codes;
• alarm/event ID with a versioned dictionary;
• units, precision, null behavior, and quality flag.

Do not embed changing content in an immutable ID. A program name may change, but its job identifier must remain traceable. If the same program runs for different batches, an execution record is needed, not overwriting a single field.

APIs, files, and databases

Some manufacturers integrate through a REST API, message broker, database view, or watched folder. Each method can work if the supplier supports it and the contract is documented.

For an API, check authentication, versioning, rate limits, idempotency, error codes, and audit. For file exchange, check atomic delivery, naming, checksum, archive, retry, and quarantine of bad files. Writing directly to the machine's internal database is generally a weak approach unless the manufacturer explicitly provides a supported interface: the schema may change and responsibility become unclear.

The existence of a technical method does not establish the right to use it. The license, warranty implications, support boundary, and update policy must be recorded in writing.

Mechanical and spatial provisions

Communications without mechanical readiness are of little use. For future loaders/unloaders, towers, or conveyors, check:

• available attachment points and load limits;
• transfer height and datum;
• moving-part envelopes and maintenance zones;
• floor load and anchoring assumptions;
• routes for sheets, skeletons, parts, and containers;
• space for cable chains, sensors, and guarding;
• crane/forklift access during installation;
• whether equipment can be installed without dismantling critical infrastructure;
• reserved utilities and isolation points.

Take dimensions only from current drawings for the specific configuration. “A typical one-meter space” is not evidence.

Electrical supply and control cabinet

Calculate spare power capacity from the future equipment, not as an arbitrary 20%. A load list, diversity, starting currents, power quality, protection coordination, and earthing concept are needed. This is a separate electrical design task, not an operator's job.

Spare DIN rail, terminal blocks, labeled gland entries, network patching, and heat-load margin are useful in the control cabinet. However, all changes must be agreed with the manufacturer: adding a power supply or switch can change the heat balance, EMC, and conformity boundary.

Documents to obtain with the machine

Minimum future-readiness package:

1. as-built electrical diagrams; 2. current I/O list and reserved channels; 3. supported protocol/options matrix; 4. data dictionary and sample payloads; 5. network interface description; 6. license list and renewal conditions; 7. backup/restore procedure and responsibility; 8. version compatibility policy; 9. safety interface description; 10. mechanical interface drawings; 11. change approval process; 12. acceptance test outline for the future interface.

If documentation is available only to the dealer or is password-protected, define who will perform integration and on what terms. Do not plan business-critical automation around an inaccessible document.

FAT now, even if automation comes later

There is nothing with which to test the full future storage scenario yet. But the foundation can be checked:

• physical presence of the option and license;
• reading sample states;
• correspondence of the I/O list to actual channels;
• a test handshake on a simulator, if permitted;
• certificate creation or a test OPC UA connection;
• a sample MTConnect response;
• timestamps and units;
• network isolation;
• documentation completeness;
• backup after commissioning.

The FAT record must contain configuration IDs, software versions, and screenshots/exports. Otherwise, three years later, it will be unclear exactly what was confirmed.

Provision selection matrix

| Future function | Minimum provision | What must not be assumed | |---|---|---| | OEE/monitoring | read-only structured data, timestamps, reason codes | that any Ethernet connection provides data | | MES job dispatch | supported job interface, IDs, acknowledgment | that a shared folder solves revision control | | loader handshake | documented operational I/O/state machine | that ready/busy covers every fault | | safety zone integration | certified safety interface and validation path | that a standard PLC signal is safe | | traceability | stable IDs, execution log, material context | that a filename is a unique ID | | remote diagnostics | approved segmented access path | that an open VPN into the machine is acceptable |

Common mistakes

• buying a communication option without a list of available data;
• mixing monitoring and machine control;
• reserving only cable, not licenses and documentation;
• treating a safety signal as ordinary I/O;
• allowing direct database writes;
• not defining the default state on communication loss;
• lacking stable job/material identifiers;
• relying on one undocumented vendor utility;
• putting all ports into the corporate network without an OT zone;
• not retaining as-built documentation and software versions;
• not checking the mechanical envelope;
• providing remote access that bypasses ART-163.

Practical pre-order checklist

• [ ] Three to five realistic future scenarios are described.
• [ ] Control, safety, monitoring, and production data are separated.
• [ ] A signal matrix with timeouts and fail states exists.
• [ ] Available I/O is confirmed for the ordered configuration itself.
• [ ] Supported OPC UA/MTConnect profiles or another API are specified.
• [ ] Sample data and a dictionary have been obtained.
• [ ] Licenses and update compatibility are defined.
• [ ] OT segmentation and a managed switch are provided for.
• [ ] Cable routes, cabinet space, attachment points, and utilities are reserved.
• [ ] Safety integration has a separate validation path.
• [ ] Documentation is included in the acceptance package.
• [ ] Current FAT checks at least basic connectivity.

Conclusion

Automation readiness is not a collection of random connectors. It is a verified path from a future use case to mechanics, power, operational signals, the safety boundary, structured data, security, and acceptance. The least expensive useful provisions usually consist of space and routes, a supported interface option, documented spare I/O, readable data, stable identifiers, and contractual access to documentation. Agree the final configuration with the manufacturer and integrator of the specific machine.

Safety boundaries

This material is not an electrical design, safety validation, network configuration, or permission to modify PLC/CNC. Do not connect external signals, switches, or software without manufacturer documentation, a risk assessment, and a competent integrator. Specific voltages, contacts, protocols, licenses, and safe states depend on the model.

Need service advice?