![\"Three](\"https://shopfloorspace.yunusemrevurgun.com/assets/articles/hazardous-area-classification-zones-divisions/ex-protection-800.webp\")
Hazardous area classification divides a plant into areas according to how likely an explosive atmosphere is to be present, then limits what equipment may be installed in each area. The IEC and ATEX system uses zones 0, 1 and 2 for gases and vapors, and zones 20, 21 and 22 for combustible dust. North American installations use Class and Division, while the National Electrical Code also recognizes a zone method. Either way the classification comes first, and an IP or NEMA enclosure rating does not replace it.
\nA classified area is one where flammable gas, vapor, mist or combustible dust may be present in a quantity that could ignite. The classification is an engineering assessment, usually recorded on an area classification drawing. It considers the substances on site, how they could be released (flanges, pump seals, vents, open tanks), and how well the area is ventilated. The IEC 60079 series is the family of standards behind it. IEC 60079-10-1 covers explosive gas atmospheres and IEC 60079-10-2 covers explosive dust, according to the Wikipedia summary of IEC 60079.
\nOnce an area is classified, every electrical device placed in it must suit that zone or division, the gas group and the temperature class. A motor, transmitter or junction box that is perfectly sound outside the area can be unsafe inside it. The classification does not depend on the device; the device must be chosen to match the classification.
\nThe European workplace directive, Directive 1999/92/EC, defines the zones in its annex. In plain terms:
\nCombustible dust uses zones 20, 21 and 22 with the same logic. The equipment side is covered by Directive 2014/34/EU, which governs equipment and protective systems for explosive atmospheres. The workplace directive decides where the zones apply, and the equipment directive governs what may be installed in them.
\nOSHA's rules for hazardous locations in 29 CFR 1910.307 recognize Class and Division designations, and also list Class I zone designations. Class I covers flammable gases and vapors, Class II covers combustible dusts, and Class III covers ignitable fibers and flyings.
\nDivision 1 describes locations where ignitable concentrations can exist under normal operating conditions. Division 2 describes locations where they are not likely under normal conditions and would be present only under abnormal conditions, most often a leak. The Wikipedia summary of IEC 60079 sets out the same definitions alongside the zone definitions.
\nThe two systems are often described as approximately equivalent: Division 1 covers zones 0 and 1, and Division 2 covers zone 2. That mapping helps when you read drawings, but it is not a one-to-one substitution for equipment selection. Equipment is certified and marked for one system or the other, and the code applied at the site decides which one governs.
\nTwo more fields matter once the zone or division is known.
\nThe gas group describes how easily a gas ignites and how much energy it takes. The IEC scheme uses groups IIA, IIB and IIC, which correspond roughly to NEC Groups D, C and A and B:
\nThe temperature class limits the maximum surface temperature of the equipment. T1 allows 450 \u00b0C and T4 allows 135 \u00b0C. The device's surface must stay below the auto-ignition temperature of the gas present, so a device rated T4 can be unsuitable for a gas whose auto-ignition temperature is lower than 135 \u00b0C. Check the substance's data, not just the area's name.
\nThree protection concepts cover much of the field equipment you will meet:
\nIntrinsic safety is the concept most instrument engineers meet in practice. Its protection depends on the whole loop, not one device. The field device, the barrier or isolator and the cable must be compatible, and the loop parameters must be checked against the certificates. The same principle now carries into networks: Ethernet-APL is designed around intrinsic safety for zones 0 and 1, with power and data sharing the same two wires.
\nAn enclosure rating says how well a device resists ingress and environmental exposure. It does not say whether the device can contain an explosion.
\nThe IP rating glossary entry and the NEMA rating entry cover the basic definitions. For panels, the control panel design basics guide matches enclosure rating to location as one of the checks before installation.
\nThe marking on certified equipment identifies the protection method, the gas or dust group, the temperature class and the zone or equipment category it is certified for. Compare each element with the area classification, not the other way round. If the marking is missing, or the certificate does not match the device revision, treat the device as unverified until the documentation is resolved.
\nFlow instruments are a common place where the classification constrains the design. The industrial flowmeter selection guide lists hazardous-area classification among the installation checks that can decide between technologies, alongside straight runs and whether the process can be stopped.
\nFor the instrumentation context, the process instrumentation learning path connects sensor, transmitter and loop decisions. Where a protective function is needed beyond control, the safety instrumented system basics article explains the boundary between control and protection.
\nNo. They describe the same underlying idea with different structures. Zones 0 and 1 roughly map to Division 1, and zone 2 to Division 2, but equipment is certified for one system, and the code applied at the site governs. Use the approved classification documents, not a conversion table.
\nNot by itself. IP67 describes ingress protection. Suitability for zone 1 depends on the explosion-protection marking, the gas group and the temperature class. A device needs an appropriate explosion-protection certificate and a suitable ingress rating.
\nNo. The classification still determines which equipment and protection level are needed in each area. Intrinsic safety is one way to make a circuit suitable for a classified area, and it depends on the loop design and the barrier parameters.
\nOnly if it is certified or otherwise suitable for that zone, gas group and temperature class. A general-purpose motor is not automatically safe because an area is less hazardous. Check the marking and the documentation, and involve the site's competent person.
\nIt sets the maximum surface temperature the equipment may reach. The surface must stay below the ignition temperature of the gas in the area. T4 allows 135 \u00b0C and T1 allows 450 \u00b0C, so a more restrictive class suits a gas with a lower ignition temperature.
\nA competent person applying the site's procedures and the applicable standard decides, normally with process engineers who know the substances and release sources. The result is a documented area classification that engineering and inspection can check.
\nA gauge repeatability and reproducibility study, usually called gauge R&R, measures how much of the variation in your readings comes from the measurement system rather than from the parts. Split that error into repeatability (the same operator measuring the same part with the same gauge) and reproducibility (different operators or conditions measuring the same part). Compare the error with the spread of the parts or with the tolerance, and you learn whether the gauge can support the decision you are making.
\nEvery reading contains the true dimension of the part and the error added by the measurement. For independent sources, the variances add: the observed variance equals the part variance plus the measurement variance. A gauge with large error therefore inflates the spread you see on a control chart or in a capability study, even when the process itself is stable.
\nThe check is easy to skip. Before you trust a process capability index, a control limit or a pass/fail count, estimate how much of the observed spread belongs to the measurement.
\nThe NIST Engineering Statistics Handbook organizes gauge studies around three levels: short-term precision (repeatability), day-to-day variation (reproducibility) and run-to-run stability. The NIST gauge R&R section describes these levels and how the data are structured.
\nOn the shop floor, the split usually looks like this:
\nThe two combine into the gauge's total R&R. Stability, whether the gauge reads the same over time, is a separate question. The NIST section on quantifying uncertainties recommends a gauge study both before and after the measurements of interest, so you can tell whether the measurement process changed in between.
\nCalibration compares an instrument with a reference standard and records its offset from that standard. Gauge blocks are a familiar example of such a standard. A gauge R&R study does not replace calibration, and calibration does not show that operators will read a part the same way.
\n![\"A](\"https://shopfloorspace.yunusemrevurgun.com/assets/articles/gauge-rr-measurement-system-analysis/gauge-blocks-800.webp\")
A gauge can be calibrated and still have poor repeatability. A repeatable gauge can also drift out of calibration. You need both properties for a measurement you intend to use.
\nPrecision only means something relative to the decision. The precision-to-tolerance (P/T) ratio compares the spread of the measurement system with the width of the specification limits. The spread is expressed as a multiple of the standard deviation, and the multiplier depends on the convention you adopt, so state it in every report.
\nA widely cited rule of thumb comes from Burdick, Borror and Montgomery's book on gauge R&R studies (2005, ISBN 0898715881). A P/T ratio below about 0.1 means the measurement system can reliably tell whether a part meets its tolerance. A ratio above about 0.3 means unacceptable parts may be measured as acceptable, or the reverse. Between those values, the decision depends on what a wrong accept or a wrong reject costs. The Wikipedia article on ANOVA gauge R&R summarizes the same guidance and cites that book.
\nThe AIAG Measurement Systems Analysis manual (4th edition, 2010) is the reference used across automotive supply chains. Where a customer or standard specifies acceptance criteria, follow those instead of the general rule above.
\nHere is an illustrative calculation with invented numbers, not a measured result. A shaft has a tolerance of 0.100 mm. The combined R&R standard deviation from the study is 0.004 mm. Using six standard deviations as the spread, the measurement spread is 0.024 mm, so P/T = 0.024 / 0.100 = 0.24. That sits in the judgment zone, and the right answer depends on the cost of misclassifying a shaft.
\nThe process capability calculator helps with the capability side of this decision, and the sample statistics calculator computes the sample standard deviation from repeated readings. Keep the intermediate numbers visible. A single ratio hides the assumptions behind it.
\nA gauge R&R study is only as good as its design. Four choices matter most:
\nFor analysis, the ANOVA method is the common choice in statistical references because it estimates the part-by-operator interaction. The simpler average-and-range method cannot separate that interaction from the rest of the error, so it can understate or misattribute the reproducibility component.
\nResolution deserves its own check. If a gauge reads in steps coarser than the variation you need to see, repeated readings collapse onto a few values, and the study will show a deceptively clean result. The same limit applies to electronic sensors: an analog input has finite resolution, as discussed in PLC analog input scaling.
\nThese are also the mistakes that make control charts and capability studies unreliable. The Cp, Cpk, Pp and Ppk choice changes how the observed spread is estimated, but it cannot remove measurement noise that was never measured.
\nWork through the cheapest causes first. Check contact, fixturing and cleanliness. Standardize the method and train operators on the same procedure. Confirm that the resolution is fine enough for the tolerance. Control the environment where temperature or vibration affects the reading. If the gauge still cannot discriminate the variation you need to see, replace it or change the decision it supports.
\nDo not adjust the process to chase noise from the gauge. Over-adjusting a process to measurement error adds variation rather than removing it, a point that matters most for the SPC signals operators act on every shift.
\nFor the wider picture of how measurement, capability and throughput fit together, the manufacturing performance learning path connects these metrics to decisions on the floor.
\nNo. Calibration compares an instrument with a reference standard and records its offset. A gauge R&R study asks whether the measurement process gives consistent results when operators, setups and parts vary. A gauge can be calibrated and still have poor repeatability, and a repeatable gauge can still be out of calibration.
\nThere is no universal cutoff. As a rule of thumb, a P/T ratio below about 0.1 generally indicates a measurement system that can reliably classify parts, and above about 0.3 generally indicates that it cannot. Between those values the decision depends on the cost of misclassification and on the acceptance criteria your customer or standard requires.
\nNo. It measures precision, meaning how much repeated readings vary. Bias, the offset from a true value, and linearity, bias across the measuring range, need calibration against reference standards. A study can show excellent precision for a gauge that is consistently wrong.
\nNo. Manual gauges such as micrometers and calipers are routinely studied. With manual tools, the reproducibility component often captures operator-to-operator differences, which can be the largest source of variation. The design should match the way the gauge is really used.
\nThe design depends on the decision, the operators you must represent and the statistical method. Choose parts across the production range and enough operators and trials to estimate each variance component. Confirm the design with a statistician or with the method your customer uses, rather than copying a number from another plant.
\nFind the cause before replacing equipment. Check contact and fixturing, the measuring method, operator training, resolution and environmental conditions. If the gauge cannot discriminate the variation you need to see, improve it, replace it or change the decision it supports.
\nTakt time sets the pace required by customer demand. Cycle time describes how often an operation actually completes a unit. Lead time measures how long a unit or order takes to travel through the chosen system. Putting all three on a board is useful only when their boundaries are clear.
\nConsider an illustrative 480-minute shift with 30 minutes of breaks and demand for 600 good units. Net available time is 450 minutes, so takt is 450 \u00d7 60 / 600 = 45 seconds per unit. The required pace is 80 units per net production hour. Reproduce the numbers in the takt time calculator.
\nSuppose a timed station completes one part every 40 seconds while running. That is its observed cycle, leaving five seconds below takt. A tagged part may still take three days to reach dispatch because it waits in batches, inspection queues and finished-goods storage. Reducing the 40-second cycle by two seconds does little for that three-day lead time unless it relieves the actual constraint or reduces queues.
\n| Measure | Start and finish | Useful question |
|---|---|---|
| Takt | Available time and demand for the same period | What completion pace is required? |
| Cycle | Repeated completion at a defined operation | Can this operation sustain the pace? |
| Production lead time | Entry to exit of the defined production stream | Where does a unit wait? |
| Order lead time | Order acceptance to customer delivery | What delivery commitment is realistic? |
Timed machine motion can omit loading, unloading, checks and replenishment. Record a complete repeating operator or machine cycle when those tasks limit output. For mixed products, retain the product and route with each observation; an overall average can hide the difficult family that consumes the schedule.
\nBreakdowns do not reduce customer demand. Subtract agreed planned exclusions when defining available time, then assess whether downtime and yield leave enough effective capacity. If the 40-second station has 90% availability and 98% good-unit yield, expected shift output is 675 \u00d7 0.90 \u00d7 0.98 = 595.35 good units, slightly below the 600-unit requirement. Use the capacity calculator to expose the gap.
\nA buffer may protect a constraint from short interruptions, but it does not create capacity. Check the OEE loss tree and line-balancing guide before buying faster equipment.
\nFollow a representative part from release to dispatch. Time the repeating work at the suspected constraint and separately record stops, queues and rejects. Review the record with operators: an omitted material-replenishment trip can matter more than the automatic cycle displayed by the PLC. Update the planning assumptions only after the boundary is agreed.
\nThe Lean Enterprise Institute definitions of takt and cycle time distinguish demand pace from observed completion. The shift and queue examples here are illustrative calculations. Continue with the manufacturing performance path.
" }, { "id": "shopfloor:original:smed-changeover-measurement", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/smed-changeover-measurement/", "title": "SMED changeover study: measure last good to first good", "summary": "Use a time observation sheet to separate internal and external work, preserve safe setup steps, and verify a repeatable changeover improvement.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "Manufacturing", "MES" ], "content_html": "A changeover study should measure the production interruption that matters to the next order. \u201cMachine stopped\u201d to \u201cmachine restarted\u201d can omit the trial pieces, adjustments and quality release that delay good output. Define the boundary as last accepted good unit of the outgoing product to first accepted good unit of the incoming product, unless your site deliberately uses another definition.
\nUse the SMED observation worksheet to record each task, its start and finish, responsible role, whether it requires a stopped machine, and what prevents preparation beforehand. Record concurrent tasks on separate rows rather than summing their durations into elapsed time.
\nAn illustrative 40-minute changeover contains ten minutes finding tooling, eight minutes installing it, twelve minutes adjusting and ten minutes validating output. Preparing verified tooling before the stop may remove much of the search interval. It does not eliminate installation, isolation or the approved release checks.
\nInternal setup requires the equipment to be stopped. External setup can be completed while the previous order runs. Moving a task outside the stop is useful only when it can be completed safely, correctly and without starving the current job of an operator or material.
\n| Task | Possible preparation | Check before changing work |
|---|---|---|
| Tool retrieval | Kit and verify tools beforehand | Correct revision and condition |
| Recipe selection | Prepare approved recipe | Authorization and version match |
| Material staging | Stage the next lot | Identity, quality status and space |
| First-piece approval | Prepare gauges and instructions | Preserve the required release decision |
SMED targets rapid setup by separating and improving these tasks. The name does not mean every process can or should achieve a sub-ten-minute changeover. Process chemistry, cleaning validation, thermal conditions and safety requirements may set a different practical boundary.
\nA second person can shorten elapsed downtime while increasing labor minutes. That can be worthwhile, but report both. Likewise, moving cleaning to another area may shift work and exposure rather than eliminate them. Review the whole route with operators, maintenance and quality before standardizing the new method.
\nMeasure multiple comparable changeovers after the change. Retain product pair, tooling, staffing and abnormal conditions; an easy same-family setup is not comparable with a full format and material change. Watch startup scrap and downstream holds so the apparent time saving does not reappear as quality loss.
\nAt the constraint, recovered changeover time can create capacity if demand exists. Elsewhere it may improve flexibility or reduce WIP rather than increase shipped output. Use takt and capacity to establish the boundary and the ROI calculator to test a documented benefit.
\nLean Enterprise Institute: single-minute exchange of die introduces the setup approach. The task breakdown above is an illustrative study plan; apply your site's approved safety and quality procedures.
" }, { "id": "shopfloor:original:roi-automation-business-case", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/roi-automation-business-case/", "title": "Automation ROI and payback: a business case operations can verify", "summary": "Separate installed cost, cash savings, released capacity and recurring expenses, then test a conservative scenario before approving automation.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "Manufacturing", "Factory Software", "Robotics" ], "content_html": "An automation proposal needs a mechanism that connects the technical change to an economic benefit. \u201cFaster cycle\u201d is not yet a benefit if the line lacks demand or another station limits output. \u201cTwo hours saved\u201d is not automatically a cash saving if the same staffing cost remains. State what changes, where it changes and how the change will be measured.
\nInclude equipment, integration, tooling, guarding, commissioning, validation, training and production disruption attributable to installation. Assign an owner to each assumption. A purchase price alone can make two proposals with very different integration burdens appear comparable.
\nRecurring costs can include licenses, support, preventive maintenance, consumables and additional inspection. Include only the incremental cost or benefit caused by the project, and avoid counting the same saving in both capacity and labor categories.
\nAn illustrative installation costs 100,000 currency units. Realizable annual gross benefit is 45,000 and additional annual operating cost is 10,000. Net annual benefit is 35,000. Simple payback is 100,000 / 35,000 = 2.8571 years. Over five years, undiscounted net gain is 35,000 \u00d7 5 \u2212 100,000 = 75,000, or a 75% horizon ROI.
\nThe ROI and payback calculator shows both horizon ROI and annual net benefit divided by investment. The latter is 35% in this example; the two percentages answer different questions.
\n| Benefit | Evidence needed |
|---|---|
| Cash labor saving | A supported reduction in actual expenditure |
| Released labor capacity | A defined reassignment and productive use |
| Additional throughput | Constraint capacity, demand and contribution |
| Lower scrap | Comparable yield, material and rework costs |
| Lower energy | Measured input and comparable operating conditions |
| Reduced downtime | Verified stop reduction and recoverable output |
Use line capacity, downtime exposure and energy cost to build the individual assumptions. Keep safety and mandatory compliance needs explicit instead of forcing every necessary investment into a speculative revenue story.
\nIf gross annual benefit falls to 30,000 with recurring cost unchanged, net benefit becomes 20,000, payback becomes five years and five-year net gain becomes zero. That sensitivity may change the installation scope, acceptance test or decision to proceed.
\nThe simple model assumes constant annual benefits and excludes discounting, financing, taxes, ramp-up, replacement expenditure and residual value. For approval, build the cash flows required by the business and review the assumptions with the responsible finance and operations owners.
\nDefine the baseline, measurement window and acceptance evidence before installation. A FAT/SAT plan can test technical behavior; it does not by itself establish financial realization. Revisit benefits after ramp-up using comparable products, schedules and boundaries. The example here is an engineering screening calculation, not an investment recommendation.
" }, { "id": "shopfloor:original:plc-fat-sat-commissioning-checklist", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/plc-fat-sat-commissioning-checklist/", "title": "PLC FAT and SAT checklist: test behavior and handover evidence", "summary": "Plan factory and site acceptance around requirements, observable results, failure states, approved changes and recoverable project files.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "PLCs", "SCADA", "Industrial Hardware" ], "content_html": "A useful acceptance test proves a requirement with an observable result. \u201cTest PLC\u201d is too broad to execute or review. \u201cWhen the simulated tank level crosses the configured high threshold, the HMI displays the specified alarm with the correct identity and timestamp\u201d gives the tester a trigger and an acceptance boundary.
\nA factory acceptance test can exercise application logic, simulated I/O, HMI behavior, configuration and agreed interfaces before shipment. A site acceptance test checks the installed wiring, actual field devices, communications, services and behavior under the site's approved conditions. A simulated input at FAT does not prove the field loop is wired correctly at SAT.
\nStart with the FAT/SAT worksheet. For each test, record requirement ID, precondition, action, expected result, actual result, evidence reference, status and approval. Keep \u201cnot tested\u201d distinct from \u201cpass.\u201d
\n| Area | Example observation | Evidence to retain |
|---|---|---|
| I/O | Correct device, channel, range and polarity | Approved loop-check record |
| Sequence | Transition requires the agreed conditions | Trend or sequence record |
| HMI | Units, state and command feedback agree | Screens and tag references |
| Communications | Loss and recovery are visible | Quality status and timestamps |
| Restart | Approved restart conditions are applied | Recovery test record |
| Handover | Project can be opened and restored | Versioned files and restore evidence |
Safety functions require their own competent validation and applicable procedures. A general PLC acceptance checklist does not establish a safety integrity or performance level. Coordinate any fault injection, power interruption or interlock test with the responsible site team and approved method.
\nA failed test should identify the exact software and hardware revision, reproducible trigger and observed deviation. Record the defect, owner and retest result. After an application change, retest affected requirements and related transitions; do not erase the original failure record.
\nFor example, changing analog scaling can affect display, alarms, trends and control calculations. A single correct HMI value does not close all those dependencies. The analog scaling guide gives a five-point check; the HMI alarm guide helps define useful operator behavior.
\nDeliver approved source projects, compiled/runtime versions where needed, device and network configurations, license dependencies, test results, known limitations and the restore procedure. Record who owns the next change. Test recovery on a suitable isolated target before calling a copied folder a backup.
\nThe OT backup guide and restore-test worksheet extend this handover. The checklist here is a practical project template; contractual acceptance criteria and site procedures determine the required tests.
" }, { "id": "shopfloor:original:plc-analog-input-scaling", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/plc-analog-input-scaling/", "title": "PLC analog input scaling: raw counts, 4\u201320 mA and diagnostics", "summary": "Map raw counts into engineering units, check the configured channel range, and keep signal-quality diagnostics separate from the displayed value.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "PLCs", "Process Automation", "Industrial Hardware" ], "content_html": "Analog scaling is an affine mapping between two known endpoints. The difficult part is usually confirming what the raw endpoints represent in the configured input channel. A number valid for one module and range can be wrong for another, even within the same controller family.
\nEngineering value = lower engineering limit + (raw \u2212 raw lower limit) \u00d7 engineering span / raw span. Raw span is raw upper limit minus raw lower limit. Validate that both spans and the chosen input representation match the channel documentation.
\nIn an illustrative module configuration where 4 mA maps to raw 0 and 20 mA maps to raw 27,648, a 0\u2013100 \u00b0C transmitter gives 50 \u00b0C at raw 13,824. That raw mapping is conditional on the module and configured range; it is not a universal PLC convention. For the electrical side, the 4\u201320 mA scaling tool maps 12 mA to 50% of span.
\nRecord expected current, raw reading and engineering display at 0%, 25%, 50%, 75% and 100%. For a 0\u2013100 \u00b0C linear transmitter, these are 4, 8, 12, 16 and 20 mA with values 0, 25, 50, 75 and 100 \u00b0C. Use suitable calibrated equipment and the approved loop-check procedure.
\nA transmitter configured for 0\u2013200 \u00b0C but software scaled for 0\u2013100 \u00b0C can look correct at the low endpoint while being wrong everywhere else. Record both device and software ranges. Check whether a square-root extraction is already applied for differential-pressure flow before adding another transform.
\nA clamped display can show a plausible minimum during a broken loop. Keep the numeric value and quality status as separate signals. Use the module's documented diagnostics for wire break, overflow, underrange and channel faults. Define how downstream logic handles bad quality, stale values and startup; the correct response depends on the process design.
\n| Symptom | First evidence to compare |
|---|---|
| Correct low point, wrong high point | Engineering span and transmitter range |
| Constant offset throughout range | Low endpoint and raw lower limit |
| Correct at midspan, wrong near ends | Range mode, nonlinear transform or saturation |
| Plausible value after disconnection | Diagnostics, hold-last-value and display clamping |
Attach channel identity, module model, range configuration, scaling parameters, calibration reference and observed points to the FAT/SAT worksheet. Include diagnostic tests only where authorized and controlled. Continue with RTD versus thermocouple selection and the instrumentation learning path.
\nSiemens S7-1200 current input representation illustrates why configured ranges and raw representations must be checked in the applicable manual. Use the documentation for the exact installed hardware.
" }, { "id": "shopfloor:original:ot-backup-restore-test-guide", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/ot-backup-restore-test-guide/", "title": "OT backup and restore testing: prove the recovery path", "summary": "Inventory the files and dependencies needed to recover a control system, set recovery objectives, and test restoration on an isolated target.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "OT Cybersecurity", "PLCs", "SCADA", "Factory Software" ], "content_html": "A successful file copy proves that bytes were copied. Recovery requires the right project, configuration, credentials, compatible tools, licenses and hardware state to work together. Treat the restore procedure as an engineering deliverable with an owner and test evidence.
\nDefine what must return to service together: controller application, HMI project, drive parameters, network-device configuration, historian definitions, server images and interface settings. Include the software versions and dependencies needed to open or deploy each artifact. Store secrets through the site's approved mechanism rather than placing them in a general spreadsheet.
\nRecord each recovery unit in the OT asset inventory and link its controlled backup location. An asset record should identify its owner and critical role, not merely an IP address.
\nRecovery point objective, or RPO, describes how much data or configuration history the operation can tolerate losing. Recovery time objective, or RTO, describes the target elapsed time to restore the agreed service. A recent backup can still take too long to restore; a fast restore can still use an unacceptably old recipe or project.
\nFor an illustrative line, the target might be recovery of the latest approved controller project within four hours. That target still needs decisions about spare hardware, engineering software, validation, and who authorizes restart. The number is a local planning assumption, not a universal OT requirement.
\nUse the restore-test worksheet to record the chosen backup, target, compatibility checks, elapsed time, expected behaviors, actual results and unresolved gaps. Use an isolated, suitable target and an approved plan that prevents recovered systems from sending unintended commands into production.
\nCheck that the project opens, required dependencies resolve, configurations match, and selected behaviors can be validated. Record evidence of the restore and its limits: opening an offline project is narrower than demonstrating an HMI and controller together. Do not describe partial evidence as full operational recovery.
\nIntegrate backups with approved changes so the inventory and restore instructions follow the installed revision. Separate backup access from ordinary workstation access where practical, protect copies against unauthorized changes, and retain a copy that survives the failure being planned for. Review retention against process and business requirements.
\nA test can expose an expired license, missing device description or undocumented password dependency before an outage. Assign those findings an owner and due date, then retest the failed step. Continue with OT incident response and the reliability and security path.
\nNIST SP 1339: OT Backup Quick Start Guide provides current guidance on backup management and recovery exercises. The worksheet and recovery-unit approach here are Shopfloor's practical implementation suggestions; site approval and process-specific validation remain necessary.
" }, { "id": "shopfloor:original:mtbf-mttr-availability-calculation", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/mtbf-mttr-availability-calculation/", "title": "MTBF and MTTR: calculate availability without hiding downtime", "summary": "A maintenance example explains operating-time denominators, repair boundaries, unfinished events and why MTBF is not an equipment lifetime.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "Manufacturing", "Industrial Hardware" ], "content_html": "MTBF summarizes operating time per failure. MTTR summarizes repair downtime per completed event. Neither tells a maintenance team what to do until the event boundary, asset population and failure consequences are visible. A machine that fails rarely but takes days to recover may deserve a different intervention from one with frequent five-minute stops.
\nSuppose one asset accumulated 1,000 operating hours, failed five times and required 20 repair hours across those five completed repairs. MTBF = 1,000 / 5 = 200 hours. MTTR = 20 / 5 = 4 hours. Repair-based availability = 200 / (200 + 4) = 98.0392%. The MTBF and MTTR calculator reproduces this example.
\nOperating time excludes the counted repair downtime. Dividing 1,020 elapsed hours by five failures would use a different numerator. Calendar availability can also include scheduled work, waiting for orders or periods when the asset was never required; label that boundary rather than mixing it into this calculation.
\nChoose whether repair duration starts at failure detection, maintenance arrival or hands-on work. Choose whether it ends at technical repair, restart or the first accepted good unit. Keep diagnosis, parts waiting and validation as separate intervals when possible. That decomposition tells you whether training, spares or the repair itself dominates recovery.
\nA repair still open at the end of the reporting period must remain visible. Excluding it makes a completed-event MTTR look better while operational downtime grows. Report open events and elapsed downtime alongside the completed-event mean.
\nAn MTBF of 200 hours does not mean the next failure arrives at hour 200, or that replacement at hour 199 is justified. A mean over several assets can mix different ages, duties and failure modes. Trend repeat failures by mechanism and duty, and use the condition-monitoring guide only where the signal can detect the relevant degradation.
\nZero observed failures is a valid observation. It does not justify an infinite reliability claim. Retain total operating hours and use an appropriate statistical model and confidence bounds when a consequential reliability claim is required.
\n| Pattern | Evidence to inspect | Candidate response |
|---|---|---|
| Frequent repeat failures | Failure mode and operating condition | Remove cause; check design or operation |
| Long parts waits | Repair timeline and stock history | Review spares and supplier lead time |
| Long restart validation | Acceptance and release steps | Improve the approved recovery procedure |
| Many minor stops | Stop timestamps and thresholds | Resolve chronic losses separately |
Connect the failure record to the CMMS workflow and preserve durations in the downtime worksheet.
\nNIST's constant repair-rate model gives the total-time to failure-count estimator and discusses inference under model assumptions. The event-boundary recommendations and example here are an operational interpretation, not a prediction of an individual asset's life.
" }, { "id": "shopfloor:original:mqtt-topic-design-industrial-data", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/mqtt-topic-design-industrial-data/", "title": "Industrial MQTT topic design: names, payloads and data contracts", "summary": "Design a stable telemetry namespace with identity, timestamps, units, quality and schema ownership before connecting dashboards and consumers.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "MQTT", "Industrial IoT / IIoT", "Sparkplug B", "Factory Software" ], "content_html": "A topic hierarchy helps route messages. It does not, by itself, tell a consumer whether a temperature is Celsius, when it was sampled, or whether the instrument is healthy. A usable industrial data contract defines both the topic's identity and the payload's meaning.
\nAn illustrative topic is site-a/area-2/line-4/filler-01/telemetry. Choose stable asset identifiers and keep display names in metadata so a renamed area does not force every consumer to resubscribe. Define the namespace owner and a migration rule before duplicating similar trees across gateways.
Document the intended hierarchy, case conventions and allowed characters. In MQTT, topic names are case-sensitive, and the + and # characters have wildcard meanings in subscription filters. Do not treat a filter as a literal publishing topic.
| Field | Example meaning | Decision to document |
|---|---|---|
| Asset ID | Stable machine identity | Registry and rename policy |
| Timestamp | When the source sampled the value | Clock, time zone and stale threshold |
| Value and unit | A numeric reading and engineering unit | Range, datatype and scaling |
| Quality | Valid, uncertain or bad observation | Mapping from source diagnostics |
| Schema version | Payload contract revision | Compatibility and migration rules |
| Sequence or event ID | Duplicate and gap handling | Scope and reset behavior |
The data-contract worksheet is a starting point for those decisions. It deliberately keeps broker credentials out of the record.
\nA retained message helps a new subscriber receive the latest retained value for a matching topic. Its presence does not prove that the device is still connected or the value is fresh. Include source timestamps and define stale behavior. Use explicit state conventions or an appropriate framework such as Sparkplug when device state needs shared semantics.
\nLikewise, QoS concerns protocol delivery between participating clients and brokers. A consumer still needs application-level rules for duplicate events, reconnects, replay and side effects. Review the MQTT delivery guide before selecting a level by intuition.
\nTelemetry and commands have different consequences. Separate their namespaces, authorization, acknowledgment and lifecycle requirements. Do not reuse a retained telemetry convention for a machine command without a process-specific design. Gateways should expose connection and source quality without allowing a dashboard outage to interfere with basic control.
\nBefore rollout, test a late subscriber, a reconnect, a stale source, a duplicate and an incompatible payload version. Record the expected consumer behavior for each. Continue through the industrial data path and UNS introduction.
\nOASIS MQTT 5.0 specifies topics, filters, retained messages and delivery behavior. The hierarchy and payload fields above are design suggestions, not a standard MQTT payload schema.
" }, { "id": "shopfloor:original:motor-power-current-efficiency", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/motor-power-current-efficiency/", "title": "Motor kW, current, efficiency and power factor: keep the quantities straight", "summary": "A three-phase example distinguishes shaft output, real input power, apparent power and running current, with the limits of a simple estimate.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "Industrial Hardware", "Energy & Sustainability", "Motion Control" ], "content_html": "Motor nameplates and energy bills describe related but different quantities. Shaft kW is mechanical output. Electrical input kW is real power entering the motor. Current also depends on supply voltage and power factor. Mixing these boundaries can understate an energy budget or misinterpret a measured current.
\nFor an illustrative 15 kW shaft output at 90% efficiency, real electrical input is 15 / 0.90 = 16.6667 kW. At a balanced 400 V line-to-line supply and power factor 0.85, the sinusoidal three-phase estimate is:
\n![Wikimedia Commons](\"https://commons.wikimedia.org/wiki/File:Principles_of_the_types_of_protection_Ex_d,_Ex_e_and_Ex_i.png\"){kind=link}
![NIST via Wikimedia Commons](\"https://commons.wikimedia.org/wiki/File:GageBlocks_011.jpg\"){kind=link}
I = shaft_kW \u00d7 1000 / (sqrt(3) \u00d7 line_voltage \u00d7 power_factor \u00d7 efficiency)The result is approximately 28.30 A. Use the motor running-current calculator to change the operating point. For single-phase AC, the analogous real-power equation omits \u221a3.
\nEfficiency converts electrical real input to mechanical output after losses. Power factor relates real input to apparent power. Improving power factor can reduce current for the same real power; it does not automatically reduce the shaft's required energy or the motor's internal losses by the same proportion.
\nEfficiency and power factor vary with operating point. Use values applicable to the actual load rather than combining a full-load efficiency with an unrelated partial-load power factor. A current measurement alone is a poor precision estimate of shaft load, especially at light load.
\nAt an average measured electrical input of 12 kW for 16 hours/day and 250 days/year, energy is 48,000 kWh/year. At 0.15 currency/kWh, the energy charge is 7,200/year. The energy cost calculator reproduces this by entering 12 kW and a 100% average power ratio, or 15 kW electrical full-load input and an 80% power ratio.
\nThat ratio describes electrical power. It is not a direct mechanical load percentage. For variable schedules, measure or sum representative operating modes and inspect demand charges separately.
\nStarting current, acceleration, supply imbalance, harmonics and VFD input behavior are outside this simple model. Do not select cable size, protective devices, overload settings or a drive from the web estimate. Use the applicable manufacturer data and electrical design requirements.
\nWhen an energy project looks promising, check the driven process too. A more efficient motor still wastes energy if it drives an unnecessary load. Connect the power evidence to plant energy management and document realizable benefits in the ROI guide.
\nU.S. Department of Energy: determining electric motor load and efficiency provides background on motor input, load and efficiency. The operating-point examples here are illustrative calculations under the stated AC assumptions.
" }, { "id": "shopfloor:original:modbus-polling-timeout-budget", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/modbus-polling-timeout-budget/", "title": "Modbus polling and timeout budget: calculate the slow path", "summary": "Estimate serial transaction time, include silent intervals and device response, and prevent offline devices from consuming the entire polling cycle.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "Modbus", "PLCs", "Industrial Networking", "Edge Computing" ], "content_html": "A polling schedule must fit healthy traffic and a bounded amount of failure handling. The fastest successful read is a weak basis for promising an update interval: an offline device can hold a serial bus until its timeout and retries expire.
\nFor an illustrative Modbus RTU exchange at 9,600 bit/s using 11 bits per character, an eight-byte request and 25-byte response occupy 33 \u00d7 11 / 9,600 = 0.0378125 seconds of wire time. That is about 37.8 ms, before silent intervals, device processing and gateway overhead.
\nThe character count depends on the configured format. Do not use an eight-data-bit count as if start, parity and stop bits consume no time. The response length also depends on the function and quantity read, so calculate it for the actual register block.
\nMeasure successful response times under representative load. Account for inter-frame timing required by the protocol and for any configured turnaround delay. Avoid combining several independently minimal observations into a cycle that no real device can sustain.
\nGroup contiguous registers only when the register map and device limits allow it. A larger read can reduce transaction overhead but may include unsupported gaps or trigger exception responses. The CRC and frame helper checks frame arithmetic; it does not establish a device's supported map.
\nSuppose a configured transaction timeout is 300 ms and the policy makes one retry after the first attempt. An unresponsive device can consume roughly 600 ms before any extra backoff, request-transmission time or gateway overhead, depending on where the timer starts. Multiply that behavior by the number of unreachable devices, not by the normal response time.
\nUse bounded retries and an offline-device backoff policy appropriate to the process. Keep last successful timestamp and communication quality visible to consumers. A gateway that republishes an old register value every second has not produced a fresh process measurement.
\n| Case | Evidence to collect |
|---|---|
| All devices healthy | Cycle duration and response distribution |
| One device unavailable | Timeout, retries and healthy-device delay |
| Several devices unavailable | Maximum cycle and backoff behavior |
| Exception response | Classification and retry decision |
| Reconnect | Recovery time and stale-value handling |
Verify register datatypes and word order separately with the Modbus register decoder. Timing cannot fix a value decoded in the wrong format. Record the polling contract in the industrial data worksheet and continue through the connectivity path.
\nModbus Organization: specifications provides the serial-line guide and application protocol resources. Consult the applicable guide and device manual for framing, timing and supported limits. The byte and timeout examples above are illustrative budgets, not universal update guarantees.
" }, { "id": "shopfloor:original:line-balancing-bottleneck-capacity", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/line-balancing-bottleneck-capacity/", "title": "Line balancing and bottleneck capacity: work from the constraint", "summary": "Estimate serial-line capacity, distinguish parallel lanes from stations, and use a small observation study before adding automation.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "Manufacturing", "MES", "Robotics" ], "content_html": "A line's output is constrained by the operation that can deliver the least effective capacity under the actual mix and operating conditions. Adding the nameplate rates of serial stations does not describe line capacity. The useful first question is which operation repeatedly prevents the next good unit from leaving the line.
\nThree operations take 30, 45 and 35 seconds per part. With independent staffing, no losses and adequate transfer, the slowest station limits the serial line to one part every 45 seconds: 80 parts/hour. The total work content is 110 seconds, but dividing an hour by 110 estimates a single resource doing all three jobs sequentially, not this three-station line.
\nIf the 45-second operation has 90% availability and 98% good yield, its effective rate becomes 80 \u00d7 0.90 \u00d7 0.98 = 70.56 good units/hour. This is a screening estimate. Stops that starve or block other stations, shared operators and variable cycles require time observations and, sometimes, a simulation.
\nTwo 45-second machines do not necessarily double output. A shared loader might only serve 100 parts/hour; a common inspection bench might accept 90. Record shared resources and measure their occupied time. The production capacity calculator treats entered lanes as independent, so do not use it to hide a common constraint.
\n| Observation | Possible implication | Next check |
|---|---|---|
| Upstream queue grows while downstream waits | Candidate constraint in the middle | Time complete cycles and interruptions |
| Candidate often waits for material | Constraint may lie upstream | Trace starvation causes |
| Candidate cannot discharge parts | Downstream blockage | Check buffers, quality holds and transfer |
| All stations wait together | Shared loss | Check utilities, staffing or schedule |
Calculate takt from the same shift and demand boundary. Then split each station's cycle into work elements: handling, processing, walking, checking and waiting. Identify tasks that can move safely to another station without creating a new constraint or making operator work inconsistent.
\nAs an illustrative lower bound, 110 seconds of work content divided by 45-second takt is 2.444, suggesting at least three fully usable parallel work resources. It does not prove three people will suffice: task precedence, machine occupation, reach, ergonomic constraints and variation can make that allocation impossible.
\nCompare good units at the line exit, WIP and operator workload before and after the change. A faster station accompanied by larger queues may only have moved the bottleneck. Keep product mix and planned time comparable, and distinguish a short demonstration from a sustainable shift result.
\nUse the downtime log to explain interruptions, the SMED observation sheet for changeovers, and the automation business-case guide when capacity evidence supports an investment.
\nLean Enterprise Institute: cycle time distinguishes machine, operator and effective cycles. The capacities above are Shopfloor's illustrative arithmetic under the stated assumptions.
" }, { "id": "shopfloor:original:historian-deadband-sampling-storage", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/historian-deadband-sampling-storage/", "title": "Historian sampling and deadband: budget storage without losing events", "summary": "Estimate raw historian volume, distinguish acquisition from storage filtering, and validate compression against the signals and events that matter.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "SCADA", "Factory Software", "Industrial IoT / IIoT", "Edge Computing" ], "content_html": "Historian storage planning starts with tag count, sampling behavior and record size. A deadband may reduce recorded values, but it also changes the evidence available to investigate a process event. Decide what must remain observable before using compression to meet a disk target.
\nFor fixed-rate storage, records per day = tags \u00d7 samples per second \u00d7 86,400. With 2,000 tags stored once every ten seconds, the estimate is 17,280,000 records/day. At an assumed 24 bytes per record, that is 414,720,000 bytes/day, or about 414.72 decimal MB. Over 30 days, the raw estimate is 12.4416 GB.
\nThis illustrative byte count excludes indexes, metadata, block structure, replication, backups and filesystem overhead. Measure the actual historian's growth on representative tags. Compression ratios from another process are weak planning evidence.
\nA source may be scanned every second while the historian stores only changes or periodic snapshots. Changing storage deadband does not necessarily reduce PLC polling or network traffic. Check each stage: source scan, gateway publish, historian ingestion and archive retention.
\nAn absolute deadband uses engineering units. A percentage deadband needs an explicit reference span. For a 0\u2013200 \u00b0C range, 0.5% of span is 1 \u00b0C; that may be too large for a process where a half-degree excursion matters. Preserve the configured range with the tag metadata.
\nSelect examples that include a slow ramp, a short excursion, a state change and bad source quality. Compare the stored trace with the source observation. Ask whether an investigator can still determine start time, peak, duration and recovery at the required resolution.
\n| Signal | Storage concern |
|---|---|
| Slowly varying analog | Deadband may work if required detail survives |
| Short excursion | Scan and archive intervals may miss the peak |
| Equipment state | Exact transitions may matter more than periodic averages |
| Counter | Reset, rollover and discontinuity need interpretation |
| Bad-quality value | Preserve quality and stale-state evidence |
A compressed display line can interpolate between points and imply behavior never sampled. Distinguish raw stored points from interpolated or aggregated views in reports.
\nDefine online retention, long-term access and recovery requirements with operations, quality and engineering. Test restoration and query performance as well as disk growth. A copied archive is not useful if the catalog, permissions or software needed to read it are missing.
\nPair this plan with the historian naming guide, the industrial data contract and OT restore testing. The calculations above are a vendor-neutral sizing baseline; archive algorithms and limits belong to the selected product's documentation.
" }, { "id": "shopfloor:original:first-pass-yield-vs-rolled-throughput-yield", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/first-pass-yield-vs-rolled-throughput-yield/", "title": "First pass yield vs rolled throughput yield: expose the rework path", "summary": "Calculate stage yield and cumulative first-time success, keep rework visible, and avoid averaging percentages across incompatible populations.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "Manufacturing", "MES", "Factory Software" ], "content_html": "First pass yield asks how many units clear a defined operation without rework or repeat processing. Rolled throughput yield combines first-pass yields across a defined sequence. Final yield can look excellent after rework while the first-pass path consumes capacity and delays orders.
\nIf 1,000 unique units enter a test operation and 920 pass on their first attempt, first pass yield is 92%. If 60 of the remaining units pass after rework, final good output can be 980, or 98% of the original entrants. Those are different measures. Counting test attempts rather than unique units can change the denominator and make both misleading.
\nRecord whether held units, diverted units and units still in progress are included. Keep product and route boundaries consistent, particularly when comparing shifts with different complexity or incoming quality.
\nFor a defined three-stage route with conditional first-pass yields of 0.98, 0.95 and 0.97, rolled throughput yield is 0.98 \u00d7 0.95 \u00d7 0.97 = 0.90307, or 90.307%. This product describes the all-first-pass route when each stage's yield is measured for the relevant population progressing along that path.
\nIt is not the arithmetic mean of 98%, 95% and 97%. It also should not combine unrelated product families, inconsistent periods or denominators that include recirculated attempts. If the data only provide an aggregate stage yield over a different mixture, label the multiplied result as an approximation.
\n| Record | Purpose |
|---|---|
| Unique unit or lot identity | Prevent counting repeated attempts as new output |
| Route and operation | Identify the applicable process path |
| First attempt result | Separate first-pass success from final acceptance |
| Rework action and repeat result | Locate capacity and material consumption |
| Final disposition | Reconcile good output, scrap and holds |
Connect these records to traceability and genealogy. A quality report should preserve the route and specification revision so a later complaint can be traced to the actual process conditions.
\nA low first-pass yield at the constraint can consume both direct rework effort and scarce production time. Compare repeat-test load, defect mechanism and downstream consequences before prioritizing. Review the measurement system before adjusting a process in response to apparent failures.
\nUse SPC to investigate variation over time and the capability calculator only with an appropriate stable data set and estimator. The OEE calculator has its own quality boundary; align definitions before transferring a first-pass figure into it. These examples are explicit arithmetic, not universal release criteria.
" }, { "id": "shopfloor:original:downtime-pareto-reason-codes", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/downtime-pareto-reason-codes/", "title": "Downtime Pareto and reason codes: make the stop log useful", "summary": "Design a small reason-code tree, separate frequency from duration, reconcile overlapping events, and attach cost assumptions to the constraint.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "Manufacturing", "MES", "Factory Software" ], "content_html": "A downtime dashboard is useful when it points to a repairable cause. Hundreds of vague operator codes and overlapping stop intervals can produce a precise-looking chart with no dependable action behind it. Start with a small event contract and reconcile it against the actual shift before adding a larger code tree.
\nRecord asset, start and end timestamps, operating state, product or order, initial reason, confirmed cause, owner and source of the observation. Keep automatic detection separate from later classification. An operator selecting \u201cjam\u201d describes a symptom; a maintenance finding of a worn guide describes a mechanism.
\nThe downtime log worksheet includes both fields. Its example row is illustrative and should be replaced with local observations. Use a defined time zone and preserve original event identifiers so corrections do not create duplicate stops.
\nAn illustrative shift has five jams lasting six minutes each, one 45-minute drive fault and ten two-minute material waits. The frequency ranking starts with material waits, then jams, then the drive fault. The duration ranking starts with the drive fault at 45 minutes, then jams at 30, then material waits at 20. Total classified duration is 95 minutes, provided the intervals do not overlap.
\nA duration Pareto prioritizes lost time. A frequency Pareto exposes repeated interruptions and operator burden. Neither captures safety consequences or the fact that a stop on a non-constraint may be absorbed by a buffer.
\nSimultaneous machine stops cannot all be added as lost line time. Use the union of relevant stopped intervals for the line boundary and retain per-asset durations for diagnosis. Define whether microstops are recorded individually or accumulated and apply the threshold consistently across periods.
\nReconcile planned production time with run time and included downtime. If the totals do not balance, investigate missing transitions, clock errors or duplicate events before interpreting OEE. Unknown reasons should remain visible; forcing every event into a plausible category hides data quality problems.
\nAssign an owner, a due date and a verification measure to the leading cause. For example, replace the guide and compare jams per 1,000 units over a comparable product mix. Check duration as well as count so fewer but longer failures do not look like an improvement.
\nThe downtime cost calculator estimates contribution at risk plus incremental incident cost. Use recoverable good-unit rate at the constraint and actual contribution assumptions. If the lost units are made later without additional cost or displaced sales, do not present their full contribution as a realized loss.
\nContinue with MTBF and MTTR boundaries, the OEE loss tree, and the manufacturing performance path. The event design and shift example here are a practical starting point, not a universal coding standard.
" }, { "id": "shopfloor:original:cp-cpk-pp-ppk-difference", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/cp-cpk-pp-ppk-difference/", "title": "Cp vs Cpk vs Pp vs Ppk: choose the right variation estimate", "summary": "Worked capability examples explain centering, within-subgroup versus overall spread, and the checks needed before interpreting an index.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "Manufacturing", "Factory Software", "Industrial AI" ], "content_html": "Capability indices compare process spread with engineering specifications. The distinction between Cp/Cpk and Pp/Ppk depends on the variation estimate, not on choosing a nicer result. Keep the time order and subgroup structure of the data so that a single index does not conceal drift or mixed production streams.
\nFor a two-sided specification, the width index is (USL \u2212 LSL) / (6 \u00d7 sigma). The centered index is the smaller of (USL \u2212 mean) / (3 \u00d7 sigma) and (mean \u2212 LSL) / (3 \u00d7 sigma). The first compares widths; the second also accounts for the mean's distance from the nearer limit.
\nWith LSL 9.5, USL 10.5, mean 10.1 and sigma 0.1, the width index is 1.6667 and the centered index is 1.3333. Moving the mean to 10.0 raises the centered index to 1.6667 without changing spread. Increasing sigma to 0.2 at mean 10.1 reduces the two indices to 0.8333 and 0.6667. Explore both changes with the capability calculator.
\nIn the convention used by Shopfloor's calculator, within-subgroup estimates produce Cp/Cpk; the overall sample standard deviation produces Pp/Ppk. An overall estimate can include shifts between subgroups that a short-term within estimate does not. Neither label rescues poor subgroup design.
\nThe sample statistics calculator returns an overall sample standard deviation. Pasting that number into the within option would mislabel the calculation. Record the estimator, sampling plan, machine, cavity, product and time window with the result.
\nSpecifications express what the product must meet. Control limits describe the observed behavior of a process under a chosen chart model. Using control limits as specifications makes capability circular: the process supplies both the output and the acceptance boundary.
\nUse a time plot and suitable SPC charts to examine stability first. Check measurement resolution and repeatability. A rounded list of identical readings can give zero sample spread even when the process is varying below the instrument's resolution.
\nA mean outside the specification interval produces a negative centered index; keep that sign. There is no universal acceptance threshold for every characteristic and customer. Distribution shape, autocorrelation, sample size and mixed streams affect interpretation. A simple index is not a defect-rate estimate without further distribution assumptions, and a point estimate omits estimation uncertainty.
\nFor an initial review, retain the raw observations, sampling plan, chart, specification revision and variation estimator. If the index affects product release, follow the approved quality procedure rather than treating a web result as a release decision.
\nNIST: process capability gives the two-sided formulas and statistical assumptions. The numeric examples are illustrative. Continue through the manufacturing performance learning path.
" }, { "id": "shopfloor:original:compressed-air-leak-cost", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/compressed-air-leak-cost/", "title": "Compressed air leak cost: turn flow estimates into verified savings", "summary": "Calculate a leak energy equivalent, keep free-air reference conditions consistent, and check compressor response before promising a saving.", "date_published": "2026-10-11T00:00:00+00:00", "tags": [ "Energy & Sustainability", "Process Automation", "Manufacturing" ], "content_html": "A leak's flow can be converted into an energy equivalent, but repairing that leak does not guarantee the electricity meter falls by exactly that amount. Compressor controls, unload behavior and system pressure determine how reduced air demand becomes reduced electrical input.
\nSuppose an illustrative leak is estimated at 500 L/min of free air. A measured specific power of 7 kW per m\u00b3/min gives 0.5 \u00d7 7 = 3.5 kW of equivalent compressor input. Over 6,000 pressurized hours, that is 21,000 kWh. At 0.15 currency/kWh, the annual energy equivalent is 3,150 currency units.
\nThe compressed air leak calculator makes these assumptions visible. Free-air flow expresses the volume at stated reference conditions; pipe-volume flow at line pressure is a different quantity. Match the conditions used by the flow estimate and compressor specific-power data.
\nA section left pressurized through nights and weekends can leak when the machines are idle. Record when the affected section is actually pressurized. Do not multiply by production hours if the air remains on longer, or by all calendar hours if it is isolated during idle periods.
\nLikewise, a leak estimate based only on hole diameter is conditional on pressure, geometry and discharge assumptions. Prefer a documented measurement or engineering estimate and retain its uncertainty. Prioritize repair using both energy significance and the process's approved maintenance practices.
\nA reduction in demand may shorten loaded time but leave a fixed-speed compressor consuming substantial unloaded power. A properly controlled system may instead stop a machine or lower speed. Look at total system kW, pressure and production before and after repair; one compressor's local meter can miss a change in sequencing across the plant.
\n| Before/after evidence | Why it matters |
|---|---|
| Comparable production and operating hours | Avoid attributing a schedule change to leak repair |
| Header and point-of-use pressure | Confirm the service requirement still holds |
| Loaded, unloaded and stopped time | Explain how demand reduction changes power |
| System input kWh | Verify the realized energy change |
| Repeat leak survey | Detect recurrence and new losses |
Tag the leak location, record the estimated free-air flow and repair date, then review a comparable operating period. Investigate apparent zero savings before assuming the repair failed: controls may need an approved adjustment, or the baseline may be too variable to resolve the change.
\nUse the industrial energy calculator for the broader schedule and tariff model. Only carry documented realizable savings into the automation business case.
\nU.S. Department of Energy: determine the cost of compressed air describes duty-dependent costs and a systems approach. The leak example here is an explicit energy-equivalent calculation, not a measured savings claim.
" }, { "id": "shopfloor:original:vibration-condition-monitoring-guide", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/vibration-condition-monitoring-guide/", "title": "Vibration condition monitoring: from sensor placement to fault frequencies", "summary": "A practical guide to vibration monitoring \u2014 accelerometers, mounting, ISO 10816 zones, envelope analysis, and the fault frequencies that name the failure.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Manufacturing", "Industrial AI", "Industrial Hardware" ], "content_html": "Vibration monitoring is the most proven predictive maintenance technology in rotating equipment: decades of physics, standardized severity zones, and fault signatures precise enough to name the failing component \u2014 inner race, outer race, misalignment, unbalance \u2014 weeks before functional failure. Programs fail not for lack of theory but for lack of discipline in sensing, baselines, and response. This guide covers the chain from accelerometer to work order.
\nMeasure velocity or acceleration at each bearing, in three axes where possible (radial horizontal, radial vertical, axial), with the sensor mounted on a solid part of the bearing housing \u2014 stud-mounted for permanent installations, never on thin covers, guards, or painted-over rust. Magnet mounts serve route-based collection; adhesive and stud mounts serve online systems. Beyond about 1 kHz of interest, mounting stiffness dominates: a hand-held probe rolls off where early bearing-defect energy lives, which is why route readings miss faults that online systems catch.
\nWireless vibration sensors have matured into a legitimate option for balance-of-plant equipment \u2014 pumps, fans, and motors where cable runs cost more than the measurement. Size the tradeoff honestly: wireless nodes sample intermittently (minutes to hours between captures) and report derived features plus occasional waveforms, while wired online systems capture continuously with full spectra. Critical machines get wired continuous monitoring; the long tail of supporting equipment gets wireless screening. Either way, confirm the sensor's frequency range, sampling rate, and temperature rating against the machine's actual fault frequencies before buying.
\nOverall levels (velocity RMS per ISO 10816/20816 zones A\u2013D) answer "how bad" with one number per machine \u2014 ideal for alarming and dashboards. Spectra (FFT) answer "what": 1\u00d7 rotational speed indicates unbalance, 2\u00d7 misalignment, blade-pass and gear-mesh frequencies point at their components, and bearing defect frequencies (BPFO, BPFI, BSF, FTF \u2014 calculable from bearing geometry) identify the exact failing element.
\nEnvelope analysis (demodulation) answers "how early": it extracts the low-frequency repetition of high-frequency impacts, revealing bearing and gear defects months before overall vibration rises. If your program skips envelope spectra, it detects failures late by construction.
\nSet alarms in two stages: alert (investigate, trend more closely) and danger (plan the intervention), with baselines captured per machine after commissioning or overhaul \u2014 identical machines vibrate differently, and fleet-average limits false-alarm the rough ones while missing drift in the smooth ones.
\nMonitoring without a response workflow is expensive telemetry. Every alert needs an owner, a diagnosis step (analyst review of spectra, not just the overall number), and a path to a planned work order in the CMMS \u2014 with feedback when the diagnosis was wrong, so alarm limits and rules improve. Feed validated data upward: clean vibration features are among the highest-value inputs to the predictive maintenance data stack, and the signal quality guide covers the aliasing, grounding, and timestamping pitfalls that corrupt analysis silently. Start with ten critical machines done well rather than two hundred done thinly; a program that catches three failures in year one gets funded for year two.
" }, { "id": "shopfloor:original:spc-statistical-process-control-guide", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/spc-statistical-process-control-guide/", "title": "Statistical process control: control charts that catch drift early", "summary": "Apply SPC where it works \u2014 control chart selection, rational subgrouping, capability indices, and the reaction plans that turn charts into control.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Manufacturing", "Factory Software", "Industrial AI" ], "content_html": "Statistical process control (SPC) distinguishes the two kinds of variation every process exhibits: common-cause noise that is always present, and special-cause signals \u2014 tool wear, material change, a drifting controller \u2014 that demand action. A control chart draws that line mathematically, so teams react to signals instead of chasing noise. Plants that run SPC well catch drift days before it becomes scrap; plants that run it badly generate charts nobody reads. The difference is in chart selection, subgrouping, and reaction discipline.
\nMatch the chart to the data. X-bar and R (or S) charts track subgrouped continuous measurements \u2014 dimensions, weights, temperatures \u2014 with the X-bar chart watching the process average and the R/S chart watching within-subgroup variation. A stable R chart with a drifting X-bar means the process center is moving; an unstable R chart means the measurement or process spread itself is changing \u2014 investigate that first.
\nIndividuals and moving range (I-MR) charts suit low-volume or slow processes where subgroups of one are all you get: batch chemistry, monthly yields, tool-life measurements. Attribute charts (p, np, c, u) track defect counts and rates where measurements are pass/fail. Respect the assumptions: control limits computed from non-normal or autocorrelated data mislead, so check distribution shape and sampling independence during setup rather than after a year of false alarms.
\nSubgroups must be sampled so that variation within a subgroup represents only short-term common-cause noise, while variation between subgroups can reveal the special causes you want to detect. Consecutive parts off one spindle, one cavity's shots in sequence, one batch's samples together \u2014 then differences between subgroups expose spindle-to-spindle, cavity-to-cavity, batch-to-batch shifts. Subgroup across cavities or machines and the chart averages away exactly the signal you need. When in doubt, stratify first (chart each stream separately) and combine later once the streams prove identical.
\nControl limits describe the process's actual behavior; specification limits describe what the customer accepts. Capability indices (Cp/Cpk for potential/actual performance) relate the two: Cpk below 1.33 means the process routinely risks the specification edge even when "in control." Compute capability only on a stable process \u2014 a drifting process has no meaningful capability number, only a repair bill.
\nEvery chart needs an out-of-control action plan (OCAP) posted with it: who responds, what to check in what order, when to quarantine product, and when to escalate. A chart without an OCAP is wall decoration. Review chart sets monthly: retire characteristics that have been stable and capable for a year (audit-sample them instead), and add charts where new failure modes appear. Feed SPC data into the quality record \u2014 electronic results attached to lots in the MES strengthen genealogy (see track and trace) and turn customer complaints into chart lookups instead of investigations.
" }, { "id": "shopfloor:original:single-pair-ethernet-apl-guide", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/single-pair-ethernet-apl-guide/", "title": "Single-pair Ethernet and APL: two wires to the field instrument", "summary": "How Single-Pair Ethernet and Ethernet-APL bring power and 10 Mbit/s Ethernet to hazardous-area field devices \u2014 and what changes in process design.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Industrial Networking", "Process Automation", "Industrial IoT / IIoT" ], "content_html": "Single-Pair Ethernet (SPE) carries Ethernet over one twisted pair instead of four, reaching 1,000 meters at 10 Mbit/s \u2014 and with power over the same pair. Ethernet-APL (Advanced Physical Layer) hardens that 10BASE-T1L physical layer for process automation: intrinsic safety for Zones 0/1, long trunk-and-spur runs, and interoperability across vendors. Together they do what fieldbus promised decades ago, but with native Ethernet: one network from the DCS to the instrument, no gateways, no protocol conversion.
\nThe classic process hierarchy \u2014 4\u201320 mA plus HART at the device, multiplexers or remote I/O concentrating signals, fieldbus or proprietary backhaul above \u2014 collapses. An APL field switch powers spur devices and connects them as full Ethernet participants; instruments expose web servers, OPC UA servers, or companion-spec information models directly. Commissioning becomes IP-address management and device-description import rather than loop checks plus multiplexer mapping, and diagnostics arrive as structured data instead of 1,200-baud polls.
\nThe trunk-and-spur topology mirrors how process plants are actually built: a 1,000-meter trunk from the control room area to field switches, with up to 200-meter spurs to instruments. Power budgeting replaces loop calculations \u2014 the APL power switch feeds the trunk, field switches feed spurs \u2014 and intrinsic-safety parameters (voltage, current, capacitance, inductance per spur) are engineered once per switch type rather than per loop.
\nFor greenfield process units, APL is now the default to beat: specify APL-capable instruments (availability grows monthly across flow, pressure, temperature, level, and valve positioners), APL field switches from the DCS vendor's approved list, and a network design that treats the APL segments as just another zone \u2014 firewalled, monitored, and patched like the rest of the OT network. Require conformance test evidence: APL's value is multi-vendor interoperability, and it only holds if procurement enforces it.
\nFor brownfield, APL usually enters through extensions and revamps: new units or heavily modified sections get APL while existing HART loops keep running \u2014 both feeding the same asset-management and historian layers above. This is the economical migration: no rip-and-replace of working loops, and each turnaround converts one more section. Coordinate with the instrument lifecycle plan so HART-to-APL swaps coincide with scheduled replacements.
\nConfirm three things with your DCS vendor: native APL switch support in the controller's engineering tooling (not a third-party island), the OPC UA companion-spec roadmap for APL instruments (the data model is where long-term value compounds \u2014 see the companion specs guide), and the cybersecurity story for hundreds of new IP endpoints in the field (certificate management, firmware signing, and network monitoring must scale down to instruments, not just servers). APL simplifies the physical layer enormously; the engineering rigor moves up the stack to information models and security \u2014 which is exactly where it belongs.
" }, { "id": "shopfloor:original:secs-gem-semiconductor-equipment", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/secs-gem-semiconductor-equipment/", "title": "SECS/GEM: the protocol stack that runs semiconductor fabs", "summary": "How SECS messages, GEM state machines, and HSMS transport connect fab equipment to MES \u2014 and what to demand in equipment acceptance.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Semiconductor", "Factory Software", "MES" ], "content_html": "Every automated wafer fab speaks SECS/GEM. The SEMI Equipment Communications Standard (SECS) defines the messages, the Generic Equipment Model (GEM, E30) defines the behavior every tool must implement \u2014 state machines, collection events, alarms, spooling \u2014 and HSMS carries it all over TCP/IP. A lithography scanner, an etcher, and a metrology tool from three vendors all expose the same GEM interface upward, which is what lets a fab MES run hundreds of tools as one factory. For the fab-level data path around it, see semiconductor fab automation.
\nHSMS (High-Speed SECS Message Services, E37) is the TCP/IP transport: connection management, message framing, and heartbeats over a single TCP connection per tool, usually initiated by the tool. It is deliberately simple \u2014 the complexity lives above it.
\nSECS-II (E5) defines the message dictionary: streams and functions (S1F1 "are you there", S6F11 event reports, S7Fxx process programs, and hundreds more) encoded in a binary list/item format. SECS-I (E4) is the legacy serial transport still found on older tools behind gateways.
\nGEM (E30) turns messages into a contract: defined equipment states (the GEM state machine every tool must implement), collection event reporting with linked data variables, alarm management, remote command handling, spooling during host outages, and clock synchronization. Compliance is verified against the GEM Compliance Statement \u2014 a standard checklist of required capabilities \u2014 which is the document to demand before accepting any tool.
\nEquipment acceptance is where GEM pays or costs for the next decade. Require the vendor's GEM compliance statement and test the claims that operations depends on: collection events fire with correct data for every production scenario (not just the demo recipe), alarms carry useful text and clear correctly, spooling survives a host outage and recovers without duplicate or lost events, and process program management (upload, download, verification) works through the host without operator console bypasses.
\nPlan the interface details jointly with MES, not after the tool arrives: the event-reporting model (which collection events, which variables attached), the trace data requirements for advanced process control, and the recipe-naming and versioning scheme. The historian tag naming guide and MES vs ERP checklist cover the naming and ownership disciplines that keep 300 tools' data joinable. Finally, treat interface froth as a lifecycle item: tool software upgrades routinely change GEM behavior, so every upgrade needs an interface regression test against the host \u2014 negotiated in the purchase contract, not discovered during production.
" }, { "id": "shopfloor:original:scada-architecture-design-guide", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/scada-architecture-design-guide/", "title": "SCADA architecture: a design guide from field to control room", "summary": "Design SCADA systems that scale \u2014 field layer, communications, servers, redundancy, and alarming \u2014 without painting the project into a corner.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "SCADA", "Industrial Networking", "Factory Software" ], "content_html": "A SCADA system is often bought as software and discovered as architecture. The screens get the attention, but availability, response time, and the cost of the tenth expansion are decided by the layers underneath: how field data is gathered, how it travels, where it is stored, and what happens when each piece fails. This guide walks the stack bottom-up so each decision lands in the right layer.
\nField layer. PLCs, RTUs, drives, and smart instruments produce the data. SCADA rarely talks to instruments directly; it polls controllers over Modbus, DNP3, OPC UA, or a native driver. Specify the polling protocol and the update-rate budget per controller up front \u2014 a SCADA server polling 5,000 points at 1 second over one serial multidrop will not meet that rate, and the failure mode is stale data that looks live. For protocol choice, see the Modbus RTU vs TCP guide and the DNP3 and utility protocols overview.
\nCommunications layer. This is where SCADA projects succeed or quietly degrade. Size bandwidth for peak poll plus alarm bursts plus historian backfill after outages \u2014 backfill is routinely forgotten and routinely saturates the link it was meant to recover over. Segment SCADA traffic from office and MES traffic per the zones and conduits model; a historian backfill should never delay an operator command.
\nServer layer. The classic pair is a real-time database (current values, alarms, trends) plus a historian (long-term storage). Keep them as separate concerns even when one product provides both, because their scaling laws differ: real-time load grows with point count times update rate, historian load with storage depth and query patterns. Redundancy belongs here \u2014 hot-standby pairs with automatic failover and automatic backfill \u2014 sized from the availability the process actually needs, not from a reflex.
\nPresentation layer. Control-room clients, web/mobile views, and reporting. Design the tag and alarm structures so new screens compose from existing objects rather than requiring new polling: template-based graphics bound to a consistent tag naming scheme are what make the fiftieth screen cheap.
\nPolling vs reporting by exception. Polling is simple and predictable; report-by-exception (DNP3 unsolicited, MQTT Sparkplug) scales to more points over thin links and timestamps at the source. Changing this later means re-engineering every field device's configuration \u2014 decide from the point count and link budget, not from habit. The Sparkplug B overview and MQTT gateway checklist cover the exception-based path.
\nAlarm philosophy. An alarm system without a philosophy becomes noise within a year. Define alarm priorities, shelving rules, and per-operator load targets before commissioning, following HMI alarm design principles and ISA-18.2. Every alarm needs a defined operator response; alarms without responses are status displays wearing an alarm costume.
\nWhere SCADA ends. SCADA supervises and records; it is not an MES, a maintenance system, or a data lake. Push work orders, genealogy, and advanced analytics to the systems built for them (see SCADA, MES, and historian boundaries) and integrate through OPC UA or a unified namespace rather than growing custom SCADA modules that only one integrator understands.
" }, { "id": "shopfloor:original:rtd-vs-thermocouple-guide", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/rtd-vs-thermocouple-guide/", "title": "RTD vs thermocouple: choosing industrial temperature sensing", "summary": "Compare RTDs and thermocouples on accuracy, range, speed, and wiring \u2014 plus when to use thermistors, IR, or fiber-optic sensing instead.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Industrial Hardware", "Process Automation", "Manufacturing" ], "content_html": "Nearly every industrial temperature measurement uses one of two sensors: the resistance temperature detector (RTD) or the thermocouple. The RTD wins on accuracy and stability; the thermocouple wins on range, ruggedness, and price. Choosing well means matching the sensor's physics to the process's actual requirements \u2014 and wiring it correctly, because most temperature "sensor problems" are installation problems.
\nAn RTD (usually a Pt100 platinum element) measures temperature through the precise, repeatable change of platinum's resistance: 100 \u03a9 at 0 \u00b0C, rising ~0.385 \u03a9/\u00b0C. Accuracy reaches \u00b10.1 \u00b0C or better with proper calibration, drift is minimal over years, and the near-linear response simplifies transmitter math. Limits: range tops out around 600\u2013850 \u00b0C, the element is fragile under severe vibration, and self-heating requires low excitation current.
\nA thermocouple joins two dissimilar metals and measures the Seebeck voltage at the junction \u2014 no excitation needed, sensing junctions that survive 1,800 \u00b0C (type B/R/S) and brutal environments, at a fraction of an RTD's price. The costs: accuracy around \u00b11\u20132 \u00b0C even with good practice, drift over time at high temperature, and cold-junction compensation that must be done right (the transmitter measures its own terminal temperature and corrects for it \u2014 a transmitter baking in a hot cabinet lies about every channel).
\n| Dimension | RTD (Pt100) | Thermocouple (K, J, N\u2026) |
|---|---|---|
| Accuracy | \u00b10.1\u20130.5 \u00b0C | \u00b11\u20132 \u00b0C typical |
| Range | \u2212200 to ~850 \u00b0C | \u2212200 to 1,800 \u00b0C by type |
| Stability/drift | Excellent | Drifts, especially at high T |
| Response | Slower (larger element) | Faster (small junction) |
| Wiring | 3- or 4-wire to cancel lead resistance | Extension wire of matching type |
| Cost | Higher | Lower |
RTDs demand 3-wire (minimum) or 4-wire connections: the extra leads let the transmitter cancel lead-wire resistance, which otherwise reads as a temperature offset that drifts with ambient conditions. Two-wire RTD wiring over long cable runs is a built-in error \u2014 never accept it for control loops.
\nThermocouples demand matching extension wire all the way to the transmitter terminals: type K wire for type K sensors, correct polarity, no copper splices in between (every junction of dissimilar metals is a new thermocouple adding its own voltage). Grounding needs a deliberate decision \u2014 grounded junctions respond faster but invite ground-loop noise; ungrounded junctions isolate at the cost of speed. And keep both sensor types' wiring away from power conductors per control panel basics: millivolt and ohm-level signals coexist poorly with VFD output cables.
\nUse thermistors for narrow-range, high-sensitivity jobs (bearing monitoring, HVAC-level precision near ambient). Use infrared pyrometers for moving, inaccessible, or contaminating targets \u2014 with emissivity characterized, not guessed. Use fiber-optic distributed sensing when one fiber must report temperature every meter along kilometers of pipeline, conveyor, or cable tray. Whichever sensor you choose, put the transmitter on a smart protocol where it pays: HART exposes sensor drift and secondary readings over existing 4\u201320 mA wiring, turning a temperature point into a diagnosable asset.
" }, { "id": "shopfloor:original:profinet-vs-ethernet-ip-vs-ethercat", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/profinet-vs-ethernet-ip-vs-ethercat/", "title": "PROFINET vs EtherNet/IP vs EtherCAT: a selection guide", "summary": "Compare PROFINET, EtherNet/IP, and EtherCAT on synchronization, cycle time, topology, tooling, and ecosystem \u2014 and pick the protocol your plant can live with.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "PROFINET", "EtherNet/IP", "EtherCAT" ], "content_html": "PROFINET, EtherNet/IP, and EtherCAT carry the large majority of new industrial Ethernet nodes, and choosing among them is one of the highest-leverage decisions in a machine or line design. All three move I/O over Ethernet; they differ in synchronization quality, engineering tooling, vendor ecosystems, and what your maintenance team already knows. This guide compares them on the dimensions that actually decide projects.
\n| Dimension | PROFINET | EtherNet/IP | EtherCAT |
|---|---|---|---|
| Synchronization | IRT + PROFIdrive clocks; sub-microsecond with planning | CIP Sync (IEEE 1588); good, network-sensitive | Distributed clocks; sub-microsecond out of the box |
| Typical cycle | 1\u20134 ms (RT); 250 \u00b5s+ (IRT) | 1\u201310 ms (RPI-based) | 100 \u00b5s\u20131 ms typical |
| Topology | Line/star/tree over switches | Line/star/tree (DLR ring option) | Logical ring over line/tree/star |
| Controller side | PLC with PROFINET interface | PLC/scanner with CIP stack | Any NIC + software stack |
| Device description | GSDML files | EDS files | ESI files |
| Ecosystem center | Siemens-led, strongest in Europe/process | Rockwell-led, strongest in North America/discrete | Beckhoff-origin, broad multi-vendor slave market |
| Safety | PROFIsafe | CIP Safety | Safety over EtherCAT (FSoE) |
| Cabling | Copper/fiber, standard switches for RT | Copper/fiber, standard or DLR switches | Standard Ethernet cable, no switches in segment |
Start with the installed base. If the plant runs Siemens PLCs, stocks PROFINET spares, and trains technicians on TIA Portal, PROFINET wins by default \u2014 and symmetrically for Rockwell/CIP shops. Protocol diversity is a permanent tax on spares, training, and 2 a.m. troubleshooting. Only a requirement the incumbent genuinely cannot meet justifies a second protocol.
\nThen check synchronization. Count the axes that must move together and the inspection or measurement that must be timestamped. Sub-millisecond synchronized motion across many axes is EtherCAT's home turf (how it works). Single-digit-millisecond I/O with modest sync needs is served well by either PROFINET RT or EtherNet/IP \u2014 see EtherNet/IP and CIP messaging for RPI and assembly sizing.
\nThen check the machine builder. OEMs standardize on one protocol for their platforms. Fighting the builder's standard means custom engineering, weaker support, and upgrade friction for the life of the machine. Specify your plant standard in the purchase spec if it matters \u2014 before the order, not at commissioning.
\nMixed plants are normal: a PROFINET process skid next to an EtherCAT packaging machine feeding an EtherNet/IP line controller. The integration points that keep this sane are gateways or multi-protocol controllers at defined boundaries, a network topology that segments protocols into their own VLANs or physical networks, and an OPC UA layer above the protocols so MES and analytics see one information model instead of three. For migrations from serial fieldbus, the PROFIBUS to PROFINET guide covers the most common transition path step by step.
" }, { "id": "shopfloor:original:plc-vs-pac-vs-soft-plc", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/plc-vs-pac-vs-soft-plc/", "title": "PLC vs PAC vs soft PLC: which controller fits the job", "summary": "Compare PLCs, PACs, and software PLCs on determinism, I/O, tooling, and cost \u2014 plus when an IPC or edge controller is the better answer.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "PLCs", "Industrial Hardware", "Edge Computing" ], "content_html": "PLC, PAC, and soft PLC are often presented as three rungs of one ladder. They are better understood as three answers to different questions: the PLC optimizes for rugged determinism, the PAC adds PC-like processing to a controller form factor, and the soft PLC trades dedicated hardware for flexibility on standard compute. Picking well means matching the controller to the timing, environment, and lifecycle the application actually has.
\nThe PLC (programmable logic controller) is purpose-built hardware running a real-time OS and the scan cycle: read inputs, execute logic, write outputs, repeat. It is fanless, wide-temperature, electrically rugged, and programmed in IEC 61131-3 languages. Its timing is bounded and verifiable, which is why safety, interlocks, and fast control stay on PLCs.
\nThe PAC (programmable automation controller) keeps the PLC's I/O and ruggedness but adds a faster processor, more memory, and often a general-purpose OS partition alongside the real-time engine \u2014 enough to run historian buffering, complex algorithms, multi-protocol gateways, and richer visualization locally. Vendors draw the PLC/PAC line differently, so treat "PAC" as a capability claim to verify (scan-time guarantees, temperature ratings, OS patching model) rather than a standard category.
\nThe soft PLC runs the control engine as software on an industrial PC, edge server, or even a virtual machine: CODESYS, vendor runtimes, or open stacks on real-time Linux. One box can host control, HMI, historian buffering, and analytics. The tradeoff is that determinism now depends on the whole software stack \u2014 hypervisor, OS, drivers \u2014 and must be engineered and re-verified, not assumed.
\n| Dimension | PLC | PAC | Soft PLC on IPC |
|---|---|---|---|
| Determinism | Guaranteed by design | Guaranteed (verify specs) | Engineered per deployment |
| Environment | Harshest: heat, vibration, EMI | Harsh, check ratings | Cabinet-grade; IPC dependent |
| Compute headroom | Modest | Generous | Largest |
| Mixed workloads (vision, ML) | Via companion modules | Onboard, bounded | Native |
| Patching/lifecycle | Vendor firmware cadence | Vendor cadence + OS partition | You own the OS lifecycle |
| Team skills | Ladder/FBD everywhere | Same + IT awareness | Controls + IT/Linux skills |
Keep interlocks, safety-adjacent logic, and sub-10 ms control on hardware PLCs or PACs with stated guarantees \u2014 that is what they are for. Reach for a soft PLC when one machine needs control plus vision inspection, data buffering, or model inference in a single box, and you have the IT discipline to manage OS patching, backups, and determinism verification over a 10\u201315 year life. For brownfield sites, the controller question is inseparable from the connectivity question: see edge gateway patterns for getting data off whatever controller you already have, and the PLC version-control problem is worth solving on any platform \u2014 soft PLCs make Git-based workflows easiest, but the discipline matters more than the tooling.
" }, { "id": "shopfloor:original:ot-incident-response-playbook", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/ot-incident-response-playbook/", "title": "OT incident response: a ransomware playbook for plants that can't just stop", "summary": "Build an OT incident response plan that respects process safety \u2014 roles, containment without shutdowns, backups that restore, and tested playbooks.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "OT Cybersecurity", "Manufacturing", "SCADA" ], "content_html": "IT incident response assumes you can isolate, power off, and rebuild. A refinery, a glass furnace, or a paper machine cannot simply be powered off \u2014 an uncontrolled shutdown endangers people, destroys equipment, and costs more than the ransom. OT incident response therefore needs its own playbook: one that puts process safety first, contains without stopping unless stopping is the safe action, and restores control systems from known-good sources. This guide outlines that playbook.
\nDefine OT-specific roles. The IT SOC cannot decide whether to trip a unit; operations owns that call. The response team needs an OT lead (usually from controls or operations engineering), an operations liaison with authority to order controlled shutdowns, IT security for forensics and enterprise containment, vendor contacts for control-system support, and a single incident commander. Put names, backups, and out-of-hours contacts in a printed call tree \u2014 ransomware encrypts the SharePoint page with the phone numbers.
\nMap what matters. You cannot protect or restore what you have not inventoried. The brownfield OT asset inventory is the foundation: every controller, workstation, and network device with its firmware, configuration backup status, and process criticality. Mark the systems whose loss forces shutdown versus those that degrade gracefully \u2014 that distinction drives every containment decision.
\nPre-authorize the hard decisions. Agree in advance, in writing, with plant management: under what conditions operations will island the plant (sever OT from IT/corporate networks), who can order it, and what production loss that implies. Negotiating this during an incident wastes the hours containment needs.
\nIslanding beats shutdown. The first containment move is usually to sever the conduits between OT and everything else \u2014 pull the uplinks at defined zone boundaries \u2014 while the process keeps running under local control. Engineer these disconnect points in advance: labeled, tested, and operable without the network (a firewall rule change that requires the management network you just lost is not a disconnect plan).
\nNever reimage a running controller to "clean" it. Forensics on control systems means capturing configurations, logs, and network traffic \u2014 not wiping the PLC that is holding the process stable. Quarantine infected Windows assets (engineering stations, HMIs, historians) by network isolation, fail over to standby systems where they exist, and keep the process on local/manual control per operating procedures.
\nCommunicate on out-of-band channels. Assume email, Teams, and VoIP are compromised or down. Incident communications run on phones, radios, runners, and a pre-established group chat on personal devices \u2014 decided and tested before the incident.
\nRestoration order follows process need: safety systems verified first, then control infrastructure, then supervisory and historian layers. Every restore needs known-good sources: offline, tested backups of controller programs, HMI projects, historian configurations, and workstation images \u2014 with restoration actually rehearsed, because a backup nobody has restored is a hypothesis. Change all shared and vendor credentials after containment; attackers harvest them first.
\nAfterward, run the blameless post-mortem within two weeks: timeline, what detected it, what contained it, what failed, and corrective actions with owners. Feed the findings into monitoring (SIEM use cases for OT, anomaly detection on control traffic), segmentation improvements, and the next tabletop exercise. Run tabletops at least annually \u2014 a playbook the team has never walked through is documentation, not capability.
" }, { "id": "shopfloor:original:mes-software-selection-guide", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/mes-software-selection-guide/", "title": "MES software selection: requirements that survive go-live", "summary": "Select manufacturing execution software that lasts \u2014 shop-floor requirements, integration ownership, vendor evaluation, and pilot criteria that predict success.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "MES", "Manufacturing", "Factory Software" ], "content_html": "MES selection fails in predictable ways: buying for the demo instead of the tenth line, underestimating integration ownership, and discovering at go-live that the "standard connectors" need six months of custom work. An MES lives for a decade or more and touches every operator, so the selection process deserves the rigor of a capital project. This guide structures it around what actually predicts success.
\nWrite the requirements from the shop floor's daily work before talking to vendors: order dispatch and sequencing, work instructions, data collection (manual and automatic), genealogy and traceability depth, quality checks and nonconformance handling, labor tracking, and downtime capture. For each, state the must-have versus nice-to-have and the transaction volumes \u2014 an MES that handles 50 work orders a day may struggle with 5,000 serialized units an hour, and the difference only shows under load testing.
\nDefine the system boundaries explicitly using the MES vs ERP checklist: which system owns routings, BOMs, inventory moves, and quality plans. Most MES disappointments are boundary disputes discovered late \u2014 two systems both claiming genealogy, neither owning rework. If serialization and traceability are core requirements, read the track and trace basics first so the requirements use the industry's vocabulary.
\nIntegration \u2014 to ERP, PLCs, historians, lab systems, and label printers \u2014 is where MES budgets die. For every interface, demand specifics: named connector versions, supported protocol revisions, who configures the mappings, and reference customers running that exact interface in production. "We integrate with SAP" is not an answer; "our certified connector supports SAP S/4HANA 2023 via MII/oData with these IDoc mappings, configured by our consultants in roughly three weeks per plant" is the beginning of one.
\nPrefer standards over adapters: ISA-95/B2MML models for ERP exchange, OPC UA for equipment data, and a unified namespace strategy so the MES consumes one coherent model rather than fifty bespoke drivers. And clarify data ownership: your production history must be exportable in usable form without the vendor's professional services \u2014 negotiate the exit in the entrance contract.
\nRun the pilot on a real production line with real operators, real volumes, and real network conditions \u2014 not the vendor's cloud sandbox. Define pass/fail criteria in advance: transaction response times at peak rate, offline behavior when the network drops (a line that stops because the MES is unreachable is a design failure), label and device integration working end to end, and operator task times no worse than the current process. Score vendors on the pilot's evidence plus lifecycle factors: upgrade cadence and cost, multi-site deployment model, validation support for regulated industries, and the financial stability to exist in ten years. The cheapest license with the most expensive integration is the most expensive MES.
" }, { "id": "shopfloor:original:io-link-explained-smart-sensors", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/io-link-explained-smart-sensors/", "title": "IO-Link explained: smart sensors without the fieldbus price", "summary": "What IO-Link adds to ordinary discrete sensors \u2014 remote configuration, diagnostics, and identification over standard 3-wire cable \u2014 and how to plan a rollout.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Industrial Hardware", "PLCs", "Industrial Networking" ], "content_html": "IO-Link is a point-to-point communication standard (IEC 61131-9) that turns ordinary binary sensors and actuators into addressable, diagnosable devices \u2014 over the same unshielded 3-wire cable they already use. A photoeye, inductive proximity switch, or valve manifold with IO-Link still switches its output in real time, but it can also report its identity, signal quality, temperature, operating hours, and fault state to the controller on request. For plants drowning in "sensor fault, cause unknown" downtime, that diagnostic channel is the entire value proposition.
\nThe architecture has three layers. IO-Link devices (sensors, actuators, hubs, RFID heads) connect point-to-point to masters, typically 4- or 8-port blocks mounted in the cabinet or the field with IP65/67 ratings. Each master aggregates its ports onto a fieldbus or industrial Ethernet uplink \u2014 PROFINET, EtherNet/IP, EtherCAT, or Modbus \u2014 and presents device data to the controller as cyclic process data plus acyclic parameter access.
\nTwo facts shape every design. First, IO-Link is strictly point-to-point with a 20-meter cable limit; it replaces the sensor cable, not the network. Second, the master is the integration point that matters: port count, uplink protocol, and how cleanly its data maps into your PLC's tag structures decide whether commissioning takes hours or days. IO-Link hubs extend one port to many discrete signals, which shrinks home-run wiring dramatically on dense machines.
\nAutomatic device replacement. The master stores each device's parameters. Swap a failed sensor for an identical one and the master downloads the configuration automatically \u2014 no laptop, no software, no transcription errors at 2 a.m. This alone justifies IO-Link on lines where sensor swaps are frequent.
\nCondition data. Smart devices report received signal strength, excess gain, temperature drift, and switching cycles. A photoeye whose margin has decayed for three weeks is a scheduled replacement, not a surprise stop. Feed these values to your maintenance system (see the CMMS implementation guide) and they become work orders before they become breakdowns.
\nIdentification and validation. Each device carries a vendor ID, device ID, and serial number the controller can read. The program can refuse to run with the wrong sensor type installed \u2014 cheap insurance against well-meaning but incorrect spares.
\nStart where diagnostics pay fastest: changeover-heavy machines, hard-to-reach sensors, and lines where sensor faults dominate the downtime Pareto. Specify masters on your plant-standard uplink protocol, confirm the PLC function blocks exist for your controller family, and standardize on one cable and connector convention. Keep the classic wiring rules \u2014 IO-Link tolerates noise well, but it shares cable trays with the same VFDs and welders everything else endures (see control panel design basics). Finally, decide up front which parameters live in the PLC project versus the device: version-controlled parameters in the project, and automatic download enabled, is the combination that makes midnight sensor swaps boring.
" }, { "id": "shopfloor:original:industrial-wireless-guide", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/industrial-wireless-guide/", "title": "Industrial wireless: Wi-Fi 6, private 5G, and LoRa compared", "summary": "Choose industrial wireless by requirements \u2014 Wi-Fi 6 for bandwidth, private 5G for mobility and determinism, LoRa and WirelessHART for sensors.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Industrial Networking", "Industrial IoT / IIoT", "Edge Computing" ], "content_html": "Wireless on the plant floor has graduated from "tablets in the warehouse" to carrying AGV control, condition-monitoring vibration streams, and thousands of sensor points. The technologies overlap less than marketing suggests: Wi-Fi 6, private 5G, LoRa/LoRaWAN, and WirelessHART answer different combinations of bandwidth, latency, range, power, and mobility. Matching the radio to the requirement is the whole game.
\nWi-Fi 6/6E is the default for high-bandwidth local coverage: tablets, scanners, cameras, and fixed equipment in halls and warehouses. OFDMA and scheduled access improve on older Wi-Fi's contention behavior, and 6 GHz spectrum (where available) escapes the congested 2.4/5 GHz bands. Limits: roaming between access points still interrupts time-critical flows (design overlap and test with the actual clients \u2014 AGVs are the classic roaming stress test), and unlicensed spectrum means no interference guarantees. Engineer it like infrastructure: site survey, channel plan, and controller-based management, not a handful of autonomous APs.
\nPrivate 5G (licensed, shared, or leased spectrum depending on jurisdiction) brings scheduled airtime, sub-10 ms latencies, seamless mobility, and network slicing that reserves capacity for control traffic. The fit: large sites, outdoor yards, fleets of mobile equipment, and applications where Wi-Fi roaming breaks control. The costs are real \u2014 spectrum arrangements, core network, radio planning, and device ecosystem maturity \u2014 so justify private 5G from mobility and determinism requirements Wi-Fi demonstrably cannot meet, not from novelty.
\nLoRa/LoRaWAN covers kilometers at milliwatts for small, infrequent payloads: tank levels, environmental sensing, asset tracking beacons, and utility metering across large sites. Data rates are bytes-per-message and duty-cycle limited \u2014 this is telemetry, not control. A private LoRaWAN gateway on-site keeps the traffic local and the operating cost minimal.
\nWirelessHART and ISA100 serve process instrumentation specifically: mesh networks of battery-powered transmitters interoperating with the HART asset-management ecosystem. For adding measurements to running units without cable trays or hot work, they remain the path of least resistance.
\nSurvey before and after. Every industrial hall is a unique RF environment \u2014 steel racking, moving cranes, welding noise, microwave dryers. A predictive survey gets the design close; a post-installation validation survey with the actual clients proves it. Re-validate after layout changes: a new rack row reshapes coverage.
\nSegment wireless like wired. Wireless clients land in the same zone and conduit architecture as everything else: sensor gateways in their own zone, AGV control isolated from guest tablets, certificates or WPA3-Enterprise authentication instead of one shared PSK taped inside a cabinet. A compromised sensor radio should reach its gateway and nothing else.
\nKeep control's timing budget end to end. Wireless adds latency and jitter that wired designs never budgeted. Verify the full path \u2014 sensor to gateway to controller to actuator \u2014 against the application's timing requirement under loaded conditions, and design the failure mode: what the AGV, the crane, or the loop does when the radio drops for five seconds. That answer belongs in the safety concept, not in a footnote.
" }, { "id": "shopfloor:original:industrial-flowmeter-selection-guide", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/industrial-flowmeter-selection-guide/", "title": "Industrial flowmeters: selecting across magnetic, Coriolis, ultrasonic, and DP", "summary": "How to select industrial flowmeters \u2014 mag, Coriolis, ultrasonic, vortex, and DP \u2014 by fluid, accuracy needs, and total installed cost.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Process Automation", "Industrial Hardware", "Energy & Sustainability" ], "content_html": "Flow is the most measured process variable after temperature and pressure \u2014 and the most commonly mis-specified, because every flowmeter technology measures something slightly different under specific conditions. Selecting well means starting from the fluid and the question being asked (control, balance, billing, or indication), then matching a technology whose physics fits, at an installed cost the application justifies.
\nElectromagnetic (mag) meters measure conductive liquids by Faraday's law: no moving parts, no pressure drop, excellent turndown, and accuracy largely independent of viscosity and density. The constraints are conductivity (needs ~5 \u00b5S/cm minimum, ruling out hydrocarbons and DI water) and full-pipe requirement. Default choice for water, wastewater, slurries, and conductive chemicals.
\nCoriolis meters measure mass flow and density directly by vibrating-tube deflection: the accuracy king (\u00b10.1% of rate) for mass balances, batching, and custody transfer, immune to flow profile. The costs are price, size/weight, and pressure drop. Specify Coriolis where mass accuracy pays \u2014 batching, blending, fiscal metering \u2014 not where indication suffices.
\nUltrasonic meters (transit-time for clean fluids, Doppler for dirty ones) measure through the pipe wall with clamp-on options that install without cutting pipe or stopping the process. Accuracy is good but installation-sensitive: flow profile, straight-run requirements, and pipe condition all matter. Unbeatable for retrofit energy audits, temporary measurement, and large lines where cutting pipe is prohibitive.
\nVortex meters shed vortices off a bluff body at a frequency proportional to velocity: one technology spanning liquids, gases, and steam with no moving parts. Watch the low-flow cutoff (vortices stop below a Reynolds threshold) and vibration sensitivity. The workhorse for steam and utility gas measurement.
\nDifferential pressure (orifice, Venturi, averaging Pitot) infers flow from a constriction's pressure drop: cheapest to buy, understood by every technician, but with permanent pressure loss, limited turndown (~3:1 without stacked transmitters), and accuracy that depends on installation geometry. Still dominant in refineries and power plants where the taps already exist.
\nFinally, treat flow data as an energy-management asset: metered steam, compressed air, and water flows are the inputs to the baselines in plant energy management. A flowmeter installed for control that also feeds the energy balance pays twice.
" }, { "id": "shopfloor:original:iec-61850-substation-automation", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/iec-61850-substation-automation/", "title": "IEC 61850: substation automation beyond hardwired interlocks", "summary": "GOOSE messaging, sampled values, and SCL engineering \u2014 what IEC 61850 changes in substations and how to plan a migration from legacy RTUs.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "SCADA", "Industrial Networking", "Energy & Sustainability" ], "content_html": "IEC 61850 replaced copper with Ethernet in the high-voltage substation. Where legacy schemes wired every interlock, trip, and indication as physical contacts between relays, 61850 relays publish those same signals as high-speed Ethernet messages and describe the entire substation in a machine-readable configuration language. The standard dominates new transmission and distribution substations worldwide, and its ideas \u2014 sampled measurement streams, peer-to-peer event messaging, formal system configuration \u2014 are spreading into DER plants, microgrids, and large industrial power systems.
\nThree communication services do most of the work. GOOSE (Generic Object Oriented Substation Event) multicasts state changes \u2014 breaker positions, interlock conditions, trip commands \u2014 directly over Ethernet with transfer times under 4 ms and continuous retransmission so subscribers detect communication loss. GOOSE replaces hardwired interlocking wiring: engineering becomes subscribing signals in software instead of pulling cable.
\nSampled values (9-2) stream digitized CT/VT measurements from merging units to relays and meters at 4,800 samples per second, so protection, metering, and power-quality functions share one measurement source with synchronized timestamps. MMS (client/server) carries the supervisory layer \u2014 SCADA reads, control commands, settings, and reports \u2014 over TCP/IP to station computers and control centers, often alongside DNP3 or IEC 60870-5-104 gateways toward legacy masters.
\nThe Substation Configuration Language (SCL, part 6) is arguably the standard's most durable contribution. Every capable device ships an ICD file describing its logical nodes and data; system tools combine these into an SCD file describing the whole substation \u2014 single-line topology, all devices, all datasets, all GOOSE subscriptions. The SCD is the as-engineered truth: testing, documentation, and future extensions all derive from it.
\nTreat the SCD as a controlled engineering document from day one. Version it, keep it synchronized with the running devices (a relay replaced without updating its CID export is a latent misoperation), and require vendors to deliver validated ICD files before FAT \u2014 malformed SCL is the most common integration delay in 61850 projects, and it is always discovered late unless explicitly tested early.
\nBrownfield migrations usually proceed bay by bay: new 61850 relays in refurbished bays, GOOSE interlocking within the new sections, and hardwired or gateway interfaces at the boundary to untouched bays. Keep three risks on the plan. First, network engineering is now protection engineering \u2014 GOOSE timing depends on VLANs, priority tagging, and redundancy (PRP/HSR), so the Ethernet design needs the same rigor as the relay settings; the network topology guide and TSN primer cover the underlying mechanisms. Second, time synchronization underpins sampled values and sequence-of-events analysis \u2014 engineer PTP properly (see the time synchronization guide). Third, cybersecurity arrives with the network: engineer zones and conduits for the substation LAN from the start, because a flat protection network reachable from the corporate WAN is an incident waiting for a date.
" }, { "id": "shopfloor:original:high-performance-hmi-isa-101", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/high-performance-hmi-isa-101/", "title": "High-performance HMI: the ISA-101 approach operators trust", "summary": "Design HMIs operators can read at a glance \u2014 grayscale abnormality display, information hierarchy, and navigation that follows ISA-101.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Factory Software", "SCADA", "Manufacturing" ], "content_html": "Most HMI screens fail the same way: a colorful P&ID replica where everything shouts and nothing prioritizes. An operator scanning forty such screens cannot tell normal from abnormal at a glance \u2014 which is the only glance that matters when a process drifts at 3 a.m. High-performance HMI, codified in the ISA-101 standard, redesigns displays around a single principle: abnormal situations should be visually obvious because normal is deliberately quiet.
\nIn a high-performance HMI, normal operating state is rendered in muted grays. Color is reserved for abnormality: red and yellow for alarms by priority, plus a small set of status colors (green for running, blue for informational) used sparingly and consistently. The effect is dramatic in practice \u2014 a screen with no color demands no attention, and any color on the wall of displays draws the eye immediately to the problem.
\nThis requires unlearning the decorative habits of traditional graphics: no 3D tanks, no photorealistic equipment, no animated flames, no red/green reliance alone (roughly 8% of male operators have red-green color vision deficiency \u2014 always pair color with shape or text). Pumps and valves are simple symbols; their state is shown by fill, outline, or label rather than by rainbow Projet colors. The freed visual bandwidth goes to what operators actually need: values near their limits, trends showing direction, and setpoints visible next to process variables.
\nISA-101 organizes displays into levels, each answering one question:
\nNavigation between levels must take at most two or three clicks, with consistent placement of navigation, alarming, and detail panes on every screen. Operators build muscle memory for emergencies; inconsistent layouts tax exactly the cognition that alarms are already consuming.
\nConverting an existing plant is a bigger change-management project than a graphics project. Start with the level-1 overview and the worst level-2 screens, and involve operators in the redesign \u2014 they know which values they actually check and which alarms they ignore. Pair the graphics work with alarm rationalization: quiet graphics plus a noisy alarm system still produces an unmanageable control room. Define a display style guide (symbols, colors, fonts, navigation, faceplate standards) and enforce it in every future project and FAT, or entropy restores the rainbow within two expansions. Measure the result in operator terms: time to detect a drifted loop, alarms per operator per hour, and \u2014 the honest metric \u2014 whether operators keep the new screens up or revert to the old ones.
" }, { "id": "shopfloor:original:hart-protocol-explained", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/hart-protocol-explained/", "title": "HART protocol explained: smart instruments on 4-20 mA wiring", "summary": "How the HART protocol overlays digital diagnostics on analog current loops, what DD files do, and when to migrate to HART-IP or Ethernet-APL.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Process Automation", "Industrial Hardware", "Industrial Networking" ], "content_html": "The Highway Addressable Remote Transducer (HART) protocol is the process industry's answer to a hard constraint: millions of installed 4\u201320 mA loops that work, are paid for, and cannot be rewired without shutdowns nobody wants. HART overlays a digital signal on the same two wires using frequency-shift keying \u2014 1,200 Hz and 2,200 Hz tones representing bits \u2014 at 1,200 baud, without disturbing the analog measurement the control system reads. The loop keeps controlling exactly as before, while asset-management software can now interrogate each instrument for its identity, range, diagnostics, and secondary measurements.
\nEvery HART device exposes a digital dataset alongside its analog primary variable: device tag, manufacturer and model, range and damping configuration, device status and extended diagnostics, and often secondary variables (a temperature transmitter may report sensor-2 value or electronics temperature). A handheld communicator or a multiplexer in the cabinet reads and writes this data, so technicians can re-range a transmitter, check for sensor drift, or read "replace sensor soon" warnings without breaking the loop.
\nDevice descriptions (DD files) define how host software interprets each instrument's parameters. In practice, this means keeping the DD library current in your asset-management tooling is a real maintenance task \u2014 an unknown DD revision turns a smart instrument back into a dumb one from the host's perspective. Standardize on one asset-management package per site and update its library on a schedule, not when someone notices a gap.
\nClassic HART's 1,200-baud multidrop mode is too slow for anything resembling real-time data collection, so modern architectures concentrate HART through multiplexers,WirelessHART gateways, or I/O cards with built-in HART modems, then carry the data upstream over Ethernet \u2014 increasingly as HART-IP. The instrument stays wired exactly as it is; only the backhaul modernizes.
\nFor greenfield process units, the question is whether to lay 4\u201320 mA plus HART at all. Single-pair Ethernet with APL now carries power and 10 Mbit/s Ethernet to field instruments in hazardous areas, which makes native Ethernet instruments with richer data models (and OPC UA companion specs) the forward-looking choice. The pragmatic rule: keep HART where loops already exist and work, since a HART-enabled brownfield instrument delivers 80% of the diagnostic value at zero wiring cost; specify Ethernet instruments for new units where the infrastructure can be built once.
\nMost plants with HART instruments capture a fraction of the available value. The usual gaps: HART-capable I/O cards installed but never licensed or wired for digital pass-through, no asset-management software connected, or DD libraries years out of date. An audit of one process unit \u2014 which instruments are HART-capable, which channels pass digital data, what the host can actually read \u2014 typically uncovers quick wins: re-ranging without work permits for loop breaking, early warning of sensor degradation, and verified as-built instrument databases. Pair it with a brownfield OT asset inventory effort and the instrument data populates itself.
" }, { "id": "shopfloor:original:ethercat-explained-distributed-clocks", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/ethercat-explained-distributed-clocks/", "title": "EtherCAT explained: on-the-fly frames and sub-microsecond synchronization", "summary": "How EtherCAT processes Ethernet frames on the fly, why distributed clocks matter for motion control, and when to choose it over PROFINET or EtherNet/IP.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "EtherCAT", "Industrial Networking", "Motion Control" ], "content_html": "EtherCAT (Ethernet for Control Automation Technology) is the fastest widely deployed industrial Ethernet protocol for synchronized motion. Where most fieldbuses give each node its own frame, EtherCAT sends a single Ethernet frame through every node in the segment, and each node reads and writes its data as the frame passes \u2014 processing on the fly, with nanosecond-level hardware latency per node. The result is cycle times down to tens of microseconds with jitter under a microsecond, using standard Ethernet cabling and ordinary network interface cards on the controller side.
\nA conventional poll reads each device in turn: one request and one response per node, with the full stack delay multiplied by the node count. EtherCAT inverts this. The controller (historically called the master) emits frames containing datagrams addressed to many nodes. Each EtherCAT slave controller chip extracts its output data from the passing frame and inserts its input data without stopping it, forwarding the frame after a delay measured in nanoseconds. One frame can serve hundreds of axes, and the segment's propagation delay grows so slowly that a 1,000-node network still updates in about 30 microseconds.
\nThe topology is a logical ring over physical line, tree, or star wiring. A break in the cable is detected and can be worked around with cable redundancy: the controller's second port closes the ring from the other direction, so a single break degrades nothing except redundancy itself.
\nRaw speed is only half the story. Multi-axis motion, high-speed inspection, and power measurement need every node to agree on when a sample was taken or an output applied. EtherCAT's distributed clocks mechanism synchronizes all node clocks to the first slave's reference clock with deviation well under a microsecond \u2014 typically tens of nanoseconds. Inputs are timestamped and outputs are latched against this shared clock, so a 32-axis gantry moves as one mechanism rather than 32 approximations of one.
\nThis is the feature to evaluate in any comparison. Competing protocols reach similar cycle times on paper, but the quality of their synchronization \u2014 and how much engineering it takes to keep it \u2014 differs substantially. See the Time-Sensitive Networking primer for how converged Ethernet approaches the same problem, and the time synchronization guide for where EtherCAT's clocks sit relative to PTP and NTP.
\nEtherCAT fits best where tight synchronization and short cycles dominate: packaging machines, robotics, semiconductor handling, printing, and test rigs. The slave hardware is inexpensive and widely available, and because the controller side needs only a standard Ethernet port plus a software stack, PC-based control pairs naturally with it.
\nIt fits less well where the plant standard, the installed base, or the maintenance team's experience points elsewhere. A PROFINET shop with trained technicians and stocked spares gains little by introducing EtherCAT for one line, and process plants with long cable runs and hazardous areas usually prefer fieldbus or Ethernet-APL designs. Diagnose the requirement honestly: if your application genuinely needs sub-millisecond synchronized I/O, EtherCAT is the shortest path; if it needs 10 ms I/O and broad vendor choice, pick the protocol your team already knows. The PROFINET vs EtherNet/IP vs EtherCAT comparison scores the three side by side, and the industrial Ethernet field guide covers the cabling and switching practices all three share.
" }, { "id": "shopfloor:original:control-valve-sizing-guide", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/control-valve-sizing-guide/", "title": "Control valve sizing: Cv, trim, and the mistakes that hunt loops", "summary": "Size control valves that regulate instead of oscillate \u2014 Cv calculation, rangeability, trim choice, and the oversizing trap behind hunting loops.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Process Automation", "PLCs", "Manufacturing" ], "content_html": "More process control problems originate at the control valve than at the controller. A valve twice the needed size forces the loop to regulate on the first 10% of travel, where resolution is coarse and deadband dominates \u2014 the classic recipe for a hunting loop that no amount of PID tuning can fix. Sizing is therefore a control activity, not a piping afterthought.
\nThe flow coefficient Cv (Kv in metric units) states the flow a valve passes at a given pressure drop: by definition, the US gallons per minute of 60 \u00b0F water passing at 1 psi drop. Sizing computes the required Cv from maximum, normal, and minimum flows with their corresponding pressure drops, then selects a valve whose installed characteristic delivers stable regulation across that range.
\nThree rules prevent most failures. Size for the real pressure drop, not the pump shutoff head minus wishful thinking \u2014 the drop available at the valve is what remains after pipe, fittings, and equipment take their share, and it changes with flow. Check all three cases: a valve sized only for maximum flow may be uncontrollable at minimum flow (startup, turndown, recycle). Target 60\u201380% open at normal flow with a valve whose rangeability (ratio of maximum to minimum controllable flow, 50:1 or better for a good globe valve) covers the minimum case. A valve running 15% open at normal rates is oversized; replace the trim or the valve before touching the tuning.
\nTrim characteristic shapes how flow responds to travel. Equal-percentage trim (flow changes by a constant percentage per unit of travel) compensates for the falling system pressure drop at high flows and is the default for most process loops. Linear trim suits level loops and situations with constant pressure drop. Quick-opening trim is for on/off service \u2014 using it for throttling guarantees poor control.
\nCavitation and flashing destroy valves and the loops around them. When liquid pressure at the vena contracta drops below vapor pressure, bubbles form and collapse downstream (cavitation \u2014 noisy, erosive) or persist (flashing). Check the application's cavitation index during sizing; anti-cavitation trim, harder materials, or a different valve style (angle, axial-flow) cost far less than replacing a chewed-up valve every turnaround \u2014 and a cavitating valve feeds noise into the measurement that makes tight control impossible.
\nInstall the valve where it can actually regulate: adequate straight runs for the associated flow measurement, the valve accessible for maintenance (bypass or removable spool for critical loops), and positioner air supply clean and dry. Specify smart positioners with HART or fieldbus diagnostics \u2014 stem travel histograms, cycle counts, and friction trends reveal sticking packing and degrading air supply before they become control problems, feeding the same asset-management workflow as HART instruments. Define the failure position (fail-open, fail-closed, fail-last) from process safety analysis, not convenience, and verify it by test \u2014 a fail-closed valve with a seized actuator fails wherever it seizes. Finally, record the sizing basis (flows, drops, fluid data) with the loop documentation: when the process is debottlenecked five years later, the next engineer needs to know whether the valve has margin or is already the constraint.
" }, { "id": "shopfloor:original:cobot-selection-deployment-guide", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/cobot-selection-deployment-guide/", "title": "Collaborative robots: selecting and deploying cobots that pay back", "summary": "Select and deploy collaborative robots with realistic payback \u2014 risk assessment, end-effectors, application fit, and integration costs beyond the arm.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Robotics", "Manufacturing", "Motion Control" ], "content_html": "A collaborative robot (cobot) is a robot arm designed to share workspace with people under defined conditions \u2014 power and force limiting, speed and separation monitoring, or hand-guiding modes per ISO 10218 and ISO/TS 15066. The technology is mature; the failures are commercial and organizational: buying the arm before validating the application, underestimating integration, or skipping the risk assessment that determines whether the cell can actually run without fencing. This guide keeps the economics honest.
\nCobots pay back fastest on dull, stable, ergonomically poor tasks: machine tending, palletizing under ~12 kg, screwdriving, dispensing, pick-and-place between fixed points, and inspection handling. Validate four things before shortlisting vendors: cycle time (cobots move slower than industrial arms by design \u2014 confirm the collaborative speed still meets takt), payload at reach (rated payload includes the gripper, part, and cabling at full extension \u2014 margin matters), repeatability versus the task (part presentation variance usually dominates arm precision \u2014 fix feeding before blaming the robot), and uptime environment (dust, coolant, temperature, and washdown narrow the field quickly).
\nPrice the application, not the arm: end-effector and tooling, force sensing if the task needs it, part presentation (feeders, trays, conveyors), PLC/safety integration, guarding or area scanners if the risk assessment requires them, and commissioning. The arm is commonly a third or less of the deployed cost. That math still works \u2014 machine-tending cells routinely pay back in 12\u201318 months across two shifts \u2014 but only when quoted completely.
\n"Collaborative" describes a system property, not an arm property. ISO 12100 risk assessment plus ISO/TS 15066 biomechanical limits determine whether your specific combination of arm, tooling, workpiece, and speeds may operate without fencing \u2014 sharp sheet-metal edges or pointed screwdrivers often fail transient-contact limits even at low speed, requiring reduced speeds, rounded tooling, or partial guarding. Document the assessment, validate the configured safety functions (force, speed, stopping time/distance) by measurement, and re-validate after every change to tooling, program, or layout.
\nRead robot cell safety basics for the full workflow from hazard list to validated mode, and design the cell's modes explicitly: collaborative production, supervised setup, and locked-out maintenance each need defined entry, indication, and exit. Train operators on what the cobot's safety system does and does not do \u2014 a workforce that trusts the arm blindly leans into the workspace it should respect.
\nStandardize early: one cobot platform per plant where possible, common gripper interfaces, shared program templates, and spares on the shelf. Log production data (cycles, faults, e-stops, intervention causes) from day one \u2014 it feeds both the payback verification and the OEE loss tree for the cell. Plan redeployment: a cobot's real advantage over fixed automation is that it can move to the next bottleneck when product mix changes, so design mounting, utilities, and programs for relocation. After the first cell proves out, the backlog of validated applications \u2014 not enthusiasm \u2014 should drive cells two through ten.
" }, { "id": "shopfloor:original:cmms-implementation-guide", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/cmms-implementation-guide/", "title": "CMMS implementation: getting maintenance data worth trusting", "summary": "Implement a CMMS that technicians actually use \u2014 asset hierarchy, PM optimization, work-order discipline, spares, and KPIs that drive decisions.", "date_published": "2026-10-04T00:00:00+00:00", "tags": [ "Manufacturing", "Factory Software", "MES" ], "content_html": "A computerized maintenance management system (CMMS) fails when it becomes a database the planner feeds and nobody reads. It succeeds when technicians trust it enough to check job history before touching a wrench \u2014 because the history is complete, the procedures are current, and the parts it promises are actually on the shelf. Implementation is therefore 20% software configuration and 80% data, process, and habit. This guide covers the parts that decide which outcome you get.
\nThe asset hierarchy \u2014 site, area, system, equipment, component \u2014 is the skeleton every work order, PM, spare part, and cost report hangs on. Design it to answer the questions maintenance actually asks: all pumps in the utilities area, all work on granulator G-3 this year, MTBF by asset class. Keep levels consistent (five to seven), name assets by function and location rather than by vendor model, and align equipment IDs with the tags and labels technicians see in the field \u2014 a work order for "P-101A" is useless if the pump is stenciled "POLY FEED 2."
\nPopulate deliberately: critical and bad-actor equipment first with full BOMs and documentation, the long tail with lean records that grow as work touches them. Importing 40,000 assets with empty fields creates a database that teaches everyone the CMMS is unreliable. The OT asset inventory approach transfers directly: walk down, verify, photograph, then record.
\nWork-order compliance is the data-quality engine: every job needs a type (corrective, preventive, predictive-follow-up), a failure code from a short enforced list, labor hours, parts used, and a close-out comment describing what was found \u2014 not "fixed." Keep the required fields minimal but non-negotiable, and make entry fast on mobile devices at the job site; a technician who must walk back to a kiosk will batch-enter Friday's jobs from memory, and memory invents data.
\nReview failure codes monthly with the crew: a rising "other/unknown" share means the list doesn't match reality \u2014 fix the list, don't blame the reporters. Close the loop visibly: show technicians the bad-actor reports and PM changes their data produced. Nothing sustains data quality like evidence that the data matters.
\nRationalize PMs instead of migrating them blindly: every inherited PM task needs a failure mode it prevents and an interval with a basis (vendor manual, history, or FMEA). Delete or extend PMs that find nothing year after year \u2014 each one consumes labor and teaches that PMs are paperwork. Convert time-based tasks to condition-based ones where sensing exists (vibration, thermography, oil analysis), with the CMMS generating follow-up work from condition alerts.
\nLink spares to assets through BOMs with min/max levels set from criticality and lead time, not from whoever shouted last. Cycle-count A-class spares; a work order promising a bearing that isn't on the shelf destroys trust faster than any software bug.
\nTrack few KPIs, act on all of them: schedule compliance, PM completion, reactive-work percentage, MTBF/MTTR on critical assets, and maintenance cost per unit of output. Publish them where the crew sees them, review with operations monthly, and tie each KPI to an action threshold \u2014 a KPI without a response is another decoration. An honest CMMS, fed by disciplined work orders, becomes the plant's maintenance memory: failure history for capital planning, PM evidence for audits, and the dataset that makes predictive maintenance possible.
" }, { "id": "shopfloor:original:vfd-selection-harmonics-basics", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/vfd-selection-harmonics-basics/", "title": "VFD selection and harmonics: what to get right before the drive arrives", "summary": "Sizing, bypass, braking, cable, and the harmonic distortion that variable-frequency drives push back onto your plant power.", "date_published": "2026-09-25T00:00:00+00:00", "tags": [ "Industrial Hardware", "Motion Control", "Energy & Sustainability" ], "content_html": "A variable-frequency drive looks like a simple box \u2014 power in, motor out, speed reference from the PLC \u2014 but most drive problems are decided before commissioning: wrong sizing, missing line protection, unshielded cable run next to signal wiring, or nobody asking what the drive does to plant power quality. Get these five areas right and commissioning becomes parameter entry instead of firefighting.
\nSize the drive for the application's torque profile. Constant-torque loads (conveyors, mixers, extruders) need full current at low speed; variable-torque loads (fans, centrifugal pumps) follow the affinity laws and are kinder to drives. Check overload ratings (typically 110\u2013150% for 60 seconds), altitude and temperature derating, and whether the duty is continuous or cyclic. An oversized drive on a tiny motor also tunes poorly \u2014 stay within the vendor's recommended motor-to-drive ratio.
\nDecide up front about bypass: across-the-line contactors that run the motor at full speed if the drive faults. Bypass makes sense for critical fans and pumps; it adds cost, panel space, and a control scheme that must interlock correctly with the drive's safeties.
\nStopping a high-inertia load or lowering a hoist pushes energy back into the drive's DC bus. Options in increasing cost and capability: coast to stop, DC injection braking, a dynamic braking chopper with resistors (sized for the duty cycle \u2014 undersized resistors overheat), or regenerative/active-front-end units that return power to the line. Size braking from the actual deceleration energy, not from rules of thumb.
\nUse shielded VFD cable with the shield bonded 360\u00b0 at both ends, keep motor leads as short as practical, and never run them in the same tray as 4\u201320 mA, encoder, or network cable. Ground the drive, motor frame, and cable shield to a common low-impedance point. Most "mystery" problems \u2014 flaky sensors, encoder faults, PLC analog noise that appeared with the new drive \u2014 trace to cable and grounding shortcuts.
\nThe drive's rectifier draws current in pulses, injecting harmonic distortion into plant power. Symptoms include overheated neutrals and transformers, nuisance breaker trips, and metering that disagrees with the utility bill. Mitigation, in order of effort:
\nMeasure before and after with a power-quality analyzer; IEEE 519 gives the distortion limits utilities enforce at the point of common coupling.
\nEnter the motor nameplate data and run the drive's autotune or rotating measurement. Set current, torque, and speed limits; ramp times that respect the mechanics; stall and phase-loss protection; and the network control word mapping (start/stop/speed/fault reset) with a defined behavior on communication loss \u2014 ramp to stop, hold last speed, or trip. Document every changed parameter; the next drive swap at midnight depends on it.
\nWhen a defect escapes, the question is never "was quality important" \u2014 it is "which units, made from which lots, shipped to which customers." Track and trace is the system that answers in hours instead of weeks. The pieces are simple individually; the value is in connecting them without gaps.
\nLot traceability tracks groups: raw-material lots consumed into production lots, shipped to customers by lot. Required in food, pharma, and automotive; usually sufficient for bulk and process industries.
\nSerialization gives every unit a unique identity (UDI in medical devices, serialized GTIN in pharma). Required where regulations or customers demand unit-level proof, and increasingly expected for warranty, anti-counterfeit, and service history. Serialization multiplies data volume and line-integration work \u2014 label printers, verifiers, cameras, and rework stations must all handle exceptions without stopping the line.
\nChoose the granularity the risk justifies: serialization where a recall costs millions or regulators require it, lot discipline everywhere else.
\nAggregation records containment: units into cases, cases onto pallets, pallets into shipments. Each parent carries the identities of its children, so scanning one pallet label resolves every unit inside. The failure mode is partial reads \u2014 a case scanned but its units missed \u2014 so aggregation stations need verification reads and a defined rework flow for broken parents. Commissioning (activating identities at pack-out) and decommissioning (samples, scrap, destruction) must be explicit events, not spreadsheet adjustments.
\nTraceability lives or dies on four records, all timestamped and all linked:
\nDesign for the recall query from day one: "given finished lot X, list every input lot" (backward) and "given input lot Y, list every finished lot and customer" (forward). If either query needs manual stitching across systems, the model has a gap. Test both directions in a mock recall at least annually \u2014 regulators and large customers increasingly require proof, not promises.
\nPrint-and-verify at the point of application, with grade thresholds that reject bad marks before they ship. Buffer label data upstream so a network outage stops labeling rather than shipping unverified product. And plan the human fallback: when the vision system faults at 2 a.m., the crew needs a written procedure for quarantine and relabeling that preserves the chain.
\nPlenty of plants still run PROFIBUS DP segments that work perfectly \u2014 and will keep working for years. Migration to PROFINET is usually driven by obsolescence (spare masters, aging repeaters), bandwidth (drives and instruments want more data), or standardization on Ethernet. The good news: a phased migration can keep every existing slave running while the new network grows around it.
\nStart with an asset inventory of each segment: master type and firmware, every slave with its GSD file version, baud rate, addresses, bus timing, repeaters, spur lengths, and termination. Capture a bus monitor trace under normal operation \u2014 error telegrams you find now are faults you will otherwise blame on the migration later. PROFIBUS faults are almost always physical layer: connectors, shielding, termination, and ground potential differences.
\nProxy/gateway migration keeps the PROFIBUS segment intact behind a PROFINET proxy (such as a PN/DP coupler). The PLC program sees PROFINET devices; the field keeps its RS-485 wiring, slaves, and timing. This is the lowest-risk pattern and often the permanent answer for healthy segments.
\nSegment-by-segment replacement swaps one DP segment at a time for PROFINET I/O and drives, reusing cable trays and panel space. Plan the GSD-to-GSDML transition per device: I/O mappings, parameter records, and diagnostics differ, so the PLC program and HMI faceplates need updates even when the field device is "the same."
\nController-first migration replaces the PLC/ PAC while proxying the existing PROFIBUS \u2014 then migrates segments at leisure. Useful when the controller is the obsolete part and the field is sound.
\nIn practice, most projects combine all three: proxy what works, replace what is obsolete or needs bandwidth, and schedule the rest across shutdowns.
\nPROFINET is Ethernet, so design it like industrial Ethernet: managed switches with MRP rings or line topologies per cell, separate VLANs or physical separation from office traffic, PROFINET-aware diagnostics (LLDP neighbor data is genuinely useful), and device naming (DCP) discipline \u2014 names, not DHCP accidents, are how controllers find devices. Set update times from application need, not from minimums; a 1 ms update on a temperature loop buys nothing but load.
\nKeep the old GSD files, bus traces, and project backups. Brownfield plants migrate in phases over years, and the next phase inherits your records.
\nEnergy is usually a plant's largest controllable cost after labor and materials \u2014 and the one managed with the least data. Motors and drives, compressed air, steam and hot water, process heating and cooling, HVAC, and lighting dominate consumption in most facilities. An energy program is simply the discipline of measuring these loads, fixing the obvious waste, and proving the savings persisted.
\nSubmetering is the foundation: main incomers plus large loads (compressors, chillers, furnaces, big motors) with interval data, not monthly totals. Fifteen-minute electrical intervals correlated with production counts reveal what monthly bills hide \u2014 idle consumption overnight, demand spikes at shift start, compressed-air baseload that never sleeps.
\nMake the data trustworthy before acting on it: verify CT ratios and polarity, confirm meter clocks agree (demand peaks need aligned intervals), and reconcile submeters against the utility meter within a few percent. An energy dashboard nobody believes is worse than none.
\nISO 50001 is a management system, not a technology: set an energy baseline, define energy performance indicators (kWh per unit, per ton, per operating hour), target significant energy uses, act, verify, and review. Its value is persistence \u2014 projects decay without the metering, accountability, and management review the standard requires. Even uncertified plants benefit from borrowing its structure.
\nAgree on the measurement boundary and adjustment method before the project: same production mix, weather-normalized where relevant, with the baseline frozen in writing. Option B (retrofit isolation, e.g. submeter the compressor) suits single systems; Option C (whole-facility bills) suits multi-measure programs. Report savings with the uncertainty stated \u2014 honest numbers survive audits and fund the next project.
\nMost control loops in a plant are PID, and most PID problems are not the algorithm \u2014 they are the tuning, the wiring of limits, or the measurement feeding the loop. A proportional-integral-derivative controller is three corrections added together: proportional reacts to the current error, integral removes the accumulated offset, and derivative resists rapid change. Understanding what each term costs, not just what it buys, is the core skill.
\nProportional output equals gain times error. More gain means a faster, stiffer response \u2014 and eventually oscillation. Proportional-only control always leaves offset: at steady state the error must be large enough to hold the output the process needs.
\nIntegral keeps adding error over time, which drives offset to zero. The price is phase lag: integral keeps pushing after the error changes sign, causing overshoot. Too much integral is the most common cause of a loop that hunts forever.
\nDerivative reacts to the rate of change of the measurement, adding damping that lets you run higher gain. The price is noise amplification \u2014 derivative on a noisy transmitter produces a jittery valve. Filter the measurement first, and put derivative on measurement rather than on error so setpoint steps do not kick the output.
\nAutotune routines in modern DCS and PLC function blocks do a reasonable first pass, but always sanity-check the result against the process: bump the setpoint a few percent and watch for overshoot, settling time, and valve travel.
\nDead time dominates everything. No tuning makes a loop with minutes of dead time respond in seconds. If the process allows it, reduce dead time physically (sensor placement, sample systems) before fighting it with math.
\nCascade and feedforward beat heroic tuning. A slow temperature loop often behaves once a fast flow slave handles disturbances (cascade), or a measured load change pre-positions the valve (feedforward). Use structure before gain.
\nWatch the valve, not just the trend. A loop that looks stable on a one-hour trend may be stroking its valve constantly. Excess travel wears packing and wastes energy; a slightly slower loop with a tenth of the movement is usually the better trade.
\nDocument the constants. Record P, I, D, filter, limits, and the reasoning in the loop folder or CMMS. The next person to touch the loop \u2014 possibly you at 3 a.m. \u2014 needs to know what "normal" was.
\nEtherNet/IP is standard Ethernet carrying the Common Industrial Protocol (CIP) \u2014 the same object model as DeviceNet and ControlNet. Devices expose objects with attributes (a drive's speed reference, a sensor's status word), and everything you do on the network is reading or writing those attributes. The confusion starts with the two messaging styles, which behave nothing alike.
\nImplicit (I/O) messaging moves real-time data over UDP multicast or unicast on a fixed schedule. Producer and consumer agree on an I/O assembly \u2014 a packed structure of inputs and outputs \u2014 and exchange it every Requested Packet Interval (RPI). There is no per-message addressing overhead because the connection setup already defined what moves. This is how a PLC owns remote I/O, talks to drives, and exchanges produced/consumed tags with other controllers.
\nThe RPI is a design choice, not a race: 5\u201320 ms suits most I/O and drives, and faster rates multiply switch and controller load. Count connections per controller and per switch \u2014 connection limits, not bandwidth, are usually what runs out first.
\nExplicit messaging is request/response over TCP (port 44818): read this attribute, write that one, upload a recipe, pull diagnostics. MSG instructions, HMI reads, and engineering tools all use explicit messaging. It is flexible and routable but not scheduled \u2014 latency varies with load, so never put closed-loop control through MSG instructions.
\nA useful mental model: implicit is the nervous system (fast, cyclic, fixed), explicit is the postal service (flexible, addressed, variable latency).
\nEach device's EDS file documents its assemblies and objects \u2014 which instance numbers carry inputs, outputs, and configuration. Match the EDS revision to firmware, or the assembly sizes in your project will not match the device and the connection will fault with an unhelpfully generic code.
\nWhen sizing a cell, budget three things: controller connection count (I/O plus produced/consumed plus HMI/MSG overhead), switch multicast load (use IGMP snooping so I/O multicast does not flood every port), and the RPI aggregate \u2014 many fast connections on one controller eventually show up as CPU load and jitter.
\nA control panel is the physical home of your automation: PLC, power supplies, drives, safety relays, terminal blocks, and the wireways connecting them. Panels outlive controllers \u2014 the same enclosure often serves through two or three control upgrades \u2014 so design for the next decade of modifications, not just for startup day.
\nDivide the panel into zones: incoming power and disconnect top-left, power distribution and supplies high, PLC and I/O central, drives and high-heat devices where airflow helps, terminal blocks along the bottom for field entry. Respect manufacturer clearances around drives and supplies \u2014 derating from cramped mounting is a silent capacity killer.
\nDo a thermal budget: sum device losses, compare against enclosure dissipation (or size the air conditioner / heat exchanger), and confirm with a temperature measurement under load. The most common panel failure is simply heat cooking power supplies and drive capacitors years early.
\nLeave 20\u201330% spare space: spare DIN rail, spare wireway capacity, spare terminals. Every panel gets modified; spares decide whether the change takes an hour or a weekend.
\nOne clean ground: a ground bus bonded to the enclosure, building steel, and every device ground, with paint removed at bonding points. Separate high-voltage power wiring from 24 VDC control and from analog/network cabling \u2014 different wireways or dividers, crossings at right angles. Feed analog and safety circuits from their own fused or breaker-protected branches so a shorted sensor does not take down the PLC supply.
\nSize conductors for load plus derating (bundling, ambient temperature), protect every wire at its source, and fuse 24 VDC branches individually \u2014 a single unfused supply means one pinched wire darkens the whole panel.
\nFerrules on stranded wire into terminals. Consistent wire colors (document the scheme on the door pocket). Every wire labeled at both ends with the same identifier as the schematic \u2014 wire numbers that match the drawings are the difference between a ten-minute fault find and a lost shift. Torque terminals to spec and re-torque after thermal cycling; loose terminations cause an outsized share of intermittent faults.
\nKeep an as-built schematic set in the door and update it on every change. A panel whose drawings lie is a safety hazard, not just an inconvenience.
\nUnder UL 508A (North America) or IEC 61439 (international), expect scrutiny of: short-circuit current ratings (every component rated for the available fault current), proper disconnect and overcurrent coordination, wire bending space, creepage and clearance distances, environmental rating of the enclosure (NEMA/IP matched to the location), and markings \u2014 voltage, phases, full-load current, SCCR, and wiring diagram references. Use listed/recognized components within their ratings; a part used outside its ratings voids the assembly's standing.
\nArc-flash labeling, lockout points, and finger-safe (IP20) terminals round out the safety picture. Design so the panel can be troubleshot live where necessary \u2014 fused test points and grouped isolation \u2014 because it will be.
\nMetal and polymer 3D printing has settled into specific factory roles where it beats machining, molding, or waiting for spares. The technology decision matters less than the workflow around it: design rules, process monitoring, post-processing, and inspection. Plants that treat printers as production equipment \u2014 with procedures and records \u2014 get value; plants that treat them as novelties get desk toys.
\nJigs, fixtures, and tooling aids. Custom grippers, drill guides, inspection nests, and shadow boards in hours instead of weeks. Polymer FDM and MJF parts handle most fixture loads; print orientation and infill decide strength.
\nSpare and obsolete parts. Brackets, guards, knobs, and ducting for aging machines \u2014 especially where the OEM no longer stocks them. Validate fit and function on non-critical parts first; safety-critical and high-load spares need engineering sign-off and material data.
\nConformal cooling and lightweighting. Metal powder-bed parts with internal cooling channels cut injection-molding cycle times; topology-optimized brackets save weight in automation and aerospace. These justify the cost of metal processes where plain geometry would not.
\nBridge production. Low-volume runs while tooling is cut, or while demand is unproven. Binder jetting and MJF economics suit hundreds to low thousands of parts.
\nProduction printing needs controls proportional to risk: locked print parameters per part number, material lot traceability (powder reuse counts for metal), first-article inspection against the model (CT scan or CMM for critical geometry), and defined post-processing \u2014 stress relief, HIP, machining of mating surfaces, surface finish specs.
\nFile management matters more than expected: versioned STL/3MF and build files tied to the work order, checksums on transfer (a corrupted slice ruins a 40-hour build), and retention policies matching the industry's record requirements.
\nCost per part honestly: machine time, material, labor (setup, depowdering, support removal, finishing, inspection), consumables, and quality overhead \u2014 against machining, molding, or inventory carrying cost. Printing usually wins on lead time and complexity, rarely on raw piece price at volume. Revisit the decision as volumes grow; the right answer at 50 parts is often wrong at 5,000.
\nSemiconductor fabs make the relationship between material, equipment, recipe, and history unusually visible. A wafer lot moves through many tools and process steps; the value of a measurement depends on which lot, recipe revision, chamber, and time produced it. Automation is therefore as much about identity and traceability as it is about motion.
\nThe lot or carrier is the business object that connects dispatch, material control, quality, and production history. Automated material handling systems (AMHS) move carriers between stockers, bays, and tools, while equipment automation manages load ports, recipes, and process execution. A location event without a lot identity is operationally incomplete.
\nKeep the identifiers consistent from MES dispatch through equipment interface and return. Record recipe version, operator or service action, tool state, chamber, carrier, and material condition. When a measurement is out of family, the system needs enough context to hold the affected population rather than only raising a generic equipment alarm.
\nEquipment interfaces can report state, alarms, variables, and process results, but the integration must preserve the tool\u2019s local interlocks and safe modes. MES or a host system can authorize a recipe and dispatch a lot; it should not bypass equipment protection. Separate the command path from high-volume telemetry and make communication failures visible.
\nUse event time, sequence numbers, and quality. Buffer at the edge when the host link is interrupted, but keep the tool\u2019s behavior deterministic and auditable. Historians and analytics should be able to answer which data was known at the time, not only reconstruct a neat story later.
\nThe operational test is a genealogy query: given a lot, can the team identify every tool, chamber, recipe revision, material movement, alarm, hold, and release decision that affected it? If the answer depends on joining spreadsheets after the fact, the automation boundary is leaking. Start with one process module, prove the identity and timestamp contracts, then extend the pattern to the next tool family.
\nThe AMR versus AGV guide explains the material-movement distinction in simpler terms. The MES integration checklist covers ownership and corrections across systems. For the wider operations map, Understanding the Shop Floor is a practical companion ebook. Fabs also preview the career question facing every automated industry: How to Remain Valuable When Intelligence Becomes Cheap is a 224-page practical book on the advantages that stay valuable as AI takes on more cognitive work.
" }, { "id": "shopfloor:original:safety-instrumented-system-basics", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/safety-instrumented-system-basics/", "title": "Safety instrumented systems: the boundary between control and protection", "summary": "Basic SIS and SIF concepts, independence, SIL targets, proof testing, bypasses, and the questions to answer before connecting safety to a control system.", "date_published": "2026-09-23T00:00:00+00:00", "tags": [ "Process Automation", "OT Cybersecurity" ], "content_html": "A safety instrumented system (SIS) provides a defined protective action when a hazardous process reaches a dangerous condition. It is not simply a second PLC with a red label, and it is not a replacement for the basic process control system (BPCS). Its design begins with hazards, consequences, initiating events, and the risk reduction a safety instrumented function (SIF) must provide.
\nA SIF has a sensor, logic solver, and final element that together detect a defined condition and move the process to a safe state. Examples may include high pressure trip, high temperature shutdown, or loss of flow protection. Write the process boundary, trip setpoint, response time, safe state, and reset policy in a way operators and maintenance can understand.
\nUse hazard analysis to determine whether a SIF is required and what target it has. Safety Integrity Level (SIL) is a reliability target for the function, not a marketing grade for one component. The complete loop, common causes, diagnostics, proof-test interval, and demand rate matter.
\nIndependence does not always mean separate buildings or vendors, but shared power, networks, cabinets, engineering tools, and maintenance errors can defeat a theoretical separation. Document which failures the SIS must survive, what it may share with the BPCS, and how a demand is recorded.
\nBypasses and overrides need authorization, indication, compensating measures, and automatic expiry where possible. Proof testing must check the complete path, including the final element. A logic solver that passes a test while a stuck valve never moves is not a functioning safety loop.
\nIEC 61511 provides the process-sector lifecycle language; the functional safety glossary entry and OT zones guide add adjacent context. Keep cybersecurity in the safety case because unauthorized changes can alter the protective function, but do not treat a firewall as the only safety barrier.
\nFor a concise map of control, safety, and plant data systems, read Understanding the Shop Floor, a practical companion ebook.
" }, { "id": "shopfloor:original:robot-cell-safety-basics", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/robot-cell-safety-basics/", "title": "Robot cell safety basics: from hazard list to validated mode", "summary": "A practical sequence for robot-cell risk assessment, safeguarding, operating modes, safety functions, and commissioning without confusing speed with safety.", "date_published": "2026-09-23T00:00:00+00:00", "tags": [ "Robotics", "OT Cybersecurity" ], "content_html": "Robot safety is a system property. A robot arm may have a certified controller, but the cell can still be unsafe because of a gripper, fixture, sharp workpiece, unexpected restart, access door, or maintenance procedure. Safety begins with the task and the people who can be exposed, not with the robot model.
\nMap normal production, teaching, setup, recovery, cleaning, and maintenance. For each mode, identify motion, stored energy, pinch points, dropped loads, tool changes, sharp edges, and unexpected paths. Include the space behind the arm and the area a person can reach through or over a guard. A risk assessment that only watches the programmed path misses faults and recovery work.
\nChoose safeguarding that matches access frequency: fixed guards, interlocked doors, presence sensing, scanners, safe speed, enabling devices, or a combination. A collaborative application is not automatically safe because it uses a cobot; force, speed, tool, payload, posture, and contact location still require validation.
\nAutomatic, manual, setup, and maintenance modes should have distinct permissions and safe speeds. A teach pendant enabling switch should not become a general bypass. Design restart behavior so closing a gate does not unexpectedly move the machine. Make the selected mode, safety state, and reason for a stop visible to the operator.
\nSafety functions need a defined response: stop category, monitored speed, safe position, torque removal, gripper release behavior, and reset conditions. The PLC or robot controller should not be the only place the safety case exists; keep the hazard, function, validation evidence, and change history together.
\nTest every safety device individually and in combinations that reflect real access. Check wiring, diagnostics, response time, restart prevention, and behavior after power restoration. Repeat tests after tooling, software, cell layout, or process changes. Record bypasses with an owner and expiry; a permanent bypass is an unapproved design change.
\nThe ROS 2 industrial robotics guide explains the software boundary between planning and safety-rated control. The cobot glossary entry is a quick terminology reference. For the larger plant context, Understanding the Shop Floor is a practical ebook companion. For the bigger question cells like this one raise \u2014 what stays valuable as robots and AI take on more of the work \u2014 see How to Remain Valuable When Intelligence Becomes Cheap, a 224-page practical book.
" }, { "id": "shopfloor:original:recipe-management-isa-88-basics", "url": "https://shopfloorspace.yunusemrevurgun.com/articles/recipe-management-isa-88-basics/", "title": "ISA-88 recipe management: keep process intent separate from equipment logic", "summary": "Procedures, parameters, equipment phases, versions, and approvals explained for batch systems that need repeatability without hard-coding every product into the controller.", "date_published": "2026-09-23T00:00:00+00:00", "tags": [ "Process Automation", "Manufacturing" ], "content_html": "Recipe management is the discipline of expressing what should be made separately from the controller logic that knows how equipment can make it. ISA-88 provides a vocabulary and model for that separation: physical models describe equipment, procedural models describe steps, and recipes describe product intent and parameters.
\nThe physical model may describe an enterprise, site, area, process cell, unit, and equipment module. The procedural model describes procedures, unit procedures, operations, and phases. A phase such as \u201ccharge material\u201d can be implemented by a unit\u2019s equipment logic while a recipe supplies the material, quantity, temperature, and time for a product.
\nThis separation lets one controller execute several products without turning the PLC into a maze of product-specific branches. It also gives operations and quality teams a place to review parameter changes without rewriting every interlock.
\nA recipe needs an identifier, revision, status, effective date, author, approval, limits, units, and the equipment or product context it is valid for. Keep the executed revision with the batch record. A value outside its allowed range should fail before a phase starts, not become a surprising process change halfway through.
\nDefine how pauses, holds, aborts, restarts, and manual interventions affect the record. Operators need a clear route for recovery; engineers need evidence of what was actually executed. A recipe system that only stores a CSV export is not a controlled production history.
\nKeep equipment capability separate from product limits. A unit phase can expose the ranges and states it supports, while the recipe selects a permitted value for a particular product. That separation makes a capability change visible: if a new agitator cannot meet the required mixing profile, the recipe should fail validation before the batch is released to it.
\nTreat recipe changes as operational changes with a review path. Compare revisions, show the affected parameter and reason, and make the effective revision unambiguous at the point of execution. A controlled recipe does not remove operator judgment; it makes the judgment and any approved exception auditable.
\nMES may own order and genealogy context while the batch engine owns execution. The DCS or PLC owns interlocks, phase logic, and safe equipment behavior. Agree on command, status, acknowledgement, and exception semantics across the boundary. The SCADA, MES, and historian guide is a useful companion for placing those responsibilities.
\nFor a broader view of plant data and control, Understanding the Shop Floor is a practical ebook companion.
" } ] }