1. Definitions

• MTBF (mean time between failures) = total operating time / number of operating intervals. Repair time is not counted as operating time.
• MTTR (mean time to repair) = total repair time / number of failures.
• Availability = MTBF / (MTBF + MTTR). This is inherent availability, which counts only failures and repairs; planned maintenance and waiting for material are not included.

2. Example

Assume a filling line ran 2,000 hours in a quarter, had 4 unplanned failures in that time, and the repairs took 12 hours in total.

• MTBF = 2,000 / 4 = 500 hours
• MTTR = 12 / 4 = 3 hours
• Availability = 500 / (500 + 3) = 99.40%

The failure rate λ = 1 / MTBF = 0.002 failures per hour. Under a constant failure rate, the probability of getting through a 100-hour block of shifts without a failure is exp(−100/500) = 81.9%; the probability of 500 failure-free hours is exp(−1) = 36.8%. So MTBF does not mean "one failure every 500 hours"; the probability of surviving one MTBF without a failure is only 36.8%.

3. Which number supports which decision?

• A low MTBF points to design, operating conditions or part quality; preventive and predictive maintenance work on this.
• A high MTTR points to organization: spare parts, diagnosis time, reaching a qualified technician. In the example, cutting MTTR from 3 hours to 1.5 raises availability from 99.40% to 99.70%. The same gain comes from halving the failures from 4 to 2 (MTBF 1,000 hours). Both give the same result, but one is an investment in the maintenance plan, the other in spares and diagnostics.
• On a serial line availabilities multiply: three of the same machine in sequence give a line availability of 0.9940³ = 98.22%. Two machines in parallel with redundancy (one running is enough) give 1 − (1 − 0.9940)² = 99.996%. This assumes independent failures and a perfect switchover; in reality the switchover takes time.

4. Four common mistakes

• Counting repair time as operating time. MTBF is inflated and availability looks better than it is.
• Counting work orders instead of failures. One failure may have three work orders; MTBF drops to a third.
• Deriving MTBF from a single quarter. The 500 hours calculated from 4 failures become 1,000 hours next quarter with 2 failures; follow the trend, not the number. For equipment with few failures, at least 10–12 months of records are needed.
• Applying the constant-failure-rate assumption to wearing parts. For bearings, belts and seals the failure rate rises with time; there exp(−t/MTBF) is optimistic and a Weibull analysis is needed.

Try it with your own records

The MTBF / MTTR calculator works from summary figures or from a failure log (start–end date-times); the data stays in your browser. To have your failure log interpreted, get in touch.

1. Basic rating life

• L10 = (C / P)^p million revolutions; p = 3 for ball bearings, p = 10/3 for roller bearings.
• L10h = L10 × 10⁶ / (60 × n) hours; n in revolutions per minute.

Example: dynamic load rating C = 25.5 kN (from the catalogue), equivalent dynamic load P = 3.1 kN, speed 1,450 rpm, ball bearing.

• C / P = 8.23
• L10 = 8.23³ = 556.6 million revolutions
• L10h = 556.6 × 10⁶ / (60 × 1,450) = 6,398 hours

With the same C, P and speed, a roller bearing (p = 10/3) gives 12,914 hours; the difference in the exponent shows why roller bearings are preferred under heavy load.

2. A small change in load changes life a lot

Because the exponent is 3, a 25% increase in load cuts life by nearly half:

• load × 0.8 → P = 2.48 kN → L10h = 12,495 hours
• load × 1.0 → P = 3.10 kN → L10h = 6,398 hours
• load × 1.25 → P = 3.88 kN → L10h = 3,276 hours

This is where the most common loss of life in the field comes from: belt tension, misalignment or unbalance raise the equivalent load, the catalogue life looks unchanged, but the real life halves. Vibration measurement does not see this load directly; it sees unbalance and misalignment, and the load is inferred from them.

3. Reliability adjustment

If you want 95% reliability instead of 90%, a1 = 0.64 (the value commonly given in ISO 281; verify against the standard or the catalogue before publishing):

• L5mh = 0.64 × 6,398 = 4,094 hours

Asking 95% of the same bearings to survive pulls the planning life from 6,398 to 4,094 hours. On critical equipment, spares and maintenance intervals are planned on this figure, not on L10.

4. The bearing needed for a target life

If 40,000 hours are targeted on this machine (at 95% reliability), the required dynamic load rating is C = 54.5 kN, 2.14 times the current bearing. The target therefore calls for a larger bearing or a lower load; it cannot be closed by maintaining more often.

Questions L10 does not answer

• Lubrication, contamination and temperature: the a_ISO factor in ISO 281 (a23 in the tool) carries them; without a catalogue value it is taken as 1 and the result is optimistic.
• Mounting errors and electrical erosion: these are not fatigue and sit outside the calculation; most early failures come from here.
• Heavy loads with P/C > 0.5: the model loses reliability in this region and the tool warns.
• When one particular bearing will fail: L10 is the lower 10% of a distribution and gives no date for a single part. The closest thing to a date is the vibration trend.

Try it with your own bearing

The bearing life L10 calculator works from C, P (or Fr, Fa with X, Y), speed and reliability; it holds no bearing data, you enter it from your catalogue. To interpret it together with the vibration trend, get in touch.

1. Example log

One month of unplanned downtime in minutes, summed by cause:

• Sensor failure: 420
• Mould change: 310
• Waiting for material: 260
• Conveyor jam: 190
• Label printer: 120
• No operator: 90
• Power cut: 60
• Other: 50

Total 1,500 minutes, that is 25 hours.

2. Share and cumulative share

• Sensor failure 28.0% → cumulative 28.0%
• Mould change 20.7% → 48.7%
• Waiting for material 17.3% → 66.0%
• Conveyor jam 12.7% → 78.7%
• Label printer 8.0% → 86.7%
• No operator 6.0% → 92.7%
• Power cut 4.0% → 96.7%
• Other 3.3% → 100%

The first point to reach the 80% threshold is the fifth cause: the "vital few" are 5 causes, 62.5% of the 8 causes, 86.7% of the total. Not 80/20 but roughly 86/63. This does not mean the data is wrong; it means downtime is spread fairly evenly across causes. On such a line, fixing a single cause reduces the total by at most 28.0%.

3. How to choose the threshold

• 80% is the usual starting point, but the real constraint is how many causes you can work on. If you have capacity for three improvements this month, the first three causes (66.0%) are your list; the threshold comes afterwards.
• If there is no large gap between the first two causes (28.0% and 20.7% in the example), tackling both together is often quicker than finishing one and moving to the next, because the root cause may be shared (in the example, the sensor failure and the conveyor jam may be at the same station).
• Ranking by duration and ranking by frequency give different lists. A single 60-minute power cut and twelve 5-minute label-printer stops per shift add up to the same total but call for different fixes. The tool takes duration; for frequency, run the same log with counts.

4. Record quality distorts the result

• If "Other" comes out as the largest slice, no Pareto is done; the cause list is fixed first. "Other" should not exceed 10%.
• Three spellings of the same cause ("sensor", "Sensor failure", "sensor failure") become three lines and sink in the ranking. The tool merges case and whitespace; it cannot merge spelling differences. The cause list must be fixed and coded.
• Is the mould change unplanned or planned? If planned, it does not belong in this list; in OEE it is a planned stop. If the two are mixed in one log, both the Pareto and the OEE come out wrong.

After Pareto

Pareto says what is large, not why it is large. For the first cause, a root-cause analysis (5 whys or a fishbone); for the second, usually a measurement (is the sensor failure really the sensor, the cable, or the PLC input?). For the money side of downtime there is the unplanned downtime cost tool, for its effect on OEE the OEE calculator.

Try it with your own log

The unplanned downtime Pareto analysis processes "cause;duration" lines in your browser and lets you change the threshold; no data goes to any server. To set up the structure of your downtime log, get in touch.

1. Cost per failure

The formula is simple:

• cost per failure = downtime hours × loss per hour + repair

An example line: 8 hours of downtime on average, a production loss of 50,000 TRY per hour, and 150,000 TRY of repair per failure.

• Loss: 8 × 50,000 = 400,000 TRY
• Repair: 150,000 TRY
• Total per failure: 550,000 TRY

Repair is less than a quarter of the total (150,000 / 550,000 ≈ 27%). The rest is invisible loss.

2. Annual cost

Assume 6 unplanned stoppages a year:

• annual cost = 6 × 550,000 = 3,300,000 TRY
• annual downtime = 6 × 8 = 48 hours

These two numbers are the most useful pair for making a maintenance meeting concrete: how much money, how many hours.

3. How much does early warning save?

Not every failure can be prevented. Vibration, temperature or current data shows some failures days ahead; others come suddenly. The calculation needs two honest assumptions:

• avoidable share: the percentage of failures that early warning can catch (25% in the example)
• planned-intervention ratio: what a caught failure costs as a planned stop, as a percentage of the unplanned cost (30% in the example)

The formula:

• savings = number of stoppages × avoidable share × cost per failure × (1 − planned-intervention ratio)

In the example: 6 × 0.25 × 550,000 × 0.70 = 577,500 TRY per year. Annual downtime also falls from 48 hours to 36, a reduction of 12 hours (48 × 0.25).

4. Payback on the investment

If the system costs 1,200,000 TRY, payback is 1,200,000 / 577,500 × 12 ≈ 24.9 months, roughly two years. How much does changing the avoidable share move the result?

• 10% → annual savings 231,000 TRY
• 20% → 462,000 TRY
• 30% → 693,000 TRY
• 40% → 924,000 TRY

Savings are directly proportional to the avoidable share, so that is the assumption most worth debating. Classifying your past failure records by asking "did this failure show a warning sign beforehand" turns the number from a guess into a measurement.

Four common mistakes

• Counting the repair invoice as the downtime cost and leaving out the lost hours.
• Not stating whether the hourly loss is based on gross revenue or contribution margin. Raw material and energy that are not consumed during a stop reduce the loss; say which one you used.
• Assuming an avoidable share close to 100%. Realistic starting values are low and rise as data accumulates.
• Deciding on a single scenario. Looking at four values, like the sensitivity table above, ties the decision to a range rather than to one assumption.

Try it with your own numbers

The unplanned downtime cost tool runs in your browser; the values you enter are not sent to any server. The defaults in the example are only examples, so enter your own line's numbers. For a predictive maintenance pilot, get in touch.

In the EU this structure is set out in the MDR (2017/745); the US FDA's UDI rule follows the same logic. The mistakes below are the ones we see most often at the label design and master data stage.

This article summarizes a software team's perspective; it is not regulatory advice. For binding requirements, refer to the applicable regulation and your notified body.

1. The same UDI-DI on every packaging level

The single device, the inner box and the case are different packaging levels, and each carries its own UDI-DI. Printing the same GTIN on the single device and on a box of ten leaves it unclear how many devices one scan represents. Shipping containers used for logistics are exempt; they use an SSCC.

What helps: keep the device and each packaging level as separate master data records, each with its quantity and the GTIN of the level below.

2. No new UDI-DI after a change

The MDR requires a new UDI-DI whenever a change could lead to misidentification of the device. The list includes the name or trade name, the model or version, single-use labelling, sterile packaging, the need for sterilization before use, the quantity in a package, and critical warnings such as containing latex or DEHP. Raising the pack quantity from 10 to 12 and keeping the same GTIN is a common mistake.

What helps: add "does this affect the UDI-DI?" as a mandatory step in the product change process.

3. Confusing Basic UDI-DI with UDI-DI

The Basic UDI-DI identifies a group of devices with the same intended purpose, risk class and essential design. It appears in EUDAMED, in the declaration of conformity and in certificates, but not on the label; the label carries the UDI-DI. Master data that keeps both in the same field produces inconsistencies between registration and label.

4. A production identifier that doesn't match how the device is controlled

The UDI-PI reflects how the manufacturer controls the device: (10) for lot-controlled devices, (21) for serialized ones, and (17) whenever there is an expiry date. An expiry date printed on the label but missing from the barcode, or only a lot encoded for a serialized device, leaves the UDI incomplete.

5. Human-readable text that differs from the barcode

The UDI appears on the label both in machine-readable form (the barcode) and in human-readable form (HRI). When the two are fed from separate template fields, one gets updated and the other is forgotten. The HRI should be generated from the barcode content; in GS1 the fields are written with identifiers in parentheses: (01)…(17)…(10)….

6. Print quality that is never measured

Small devices have little label space, and the symbol gets shrunk. A barcode that scans is not enough; quality grades are measured with ISO/IEC 15415 for 2D symbols and ISO/IEC 15416 for linear barcodes. Periodic measurement with a verifier reduces the risk of unreadable labels in the field.

Quick check

You can split the barcode content of a label into its fields with the GS1 barcode decoder and check that the device identifier and a production identifier are present. GTIN check digits can be verified in bulk with the check digit calculator. If you want to look at labelling and UDI database integration together, get in touch.

The situations below are where the relationship breaks most often. What they have in common is a physical event on the line that never reaches the software.

1. A rejected pack stays in the record

The camera rejects a pack and it is ejected; but if the pack had already been assigned to a case, or the reject never reached the aggregation station, it stays in the record. The reverse also happens: a pack put back on the line by hand after a reject is never assigned to any case.

What helps: record the reject decision and the physical ejection as one event, and let the aggregation station accept only serial numbers that passed verification.

2. Partial cases

At the end of a batch the last case is not full. If the partial case is not closed explicitly in the software, the system may try to add the next batch's packs to the same case, and batches get mixed.

What helps: closing the batch must close the partial case; the case record holds the actual quantity, and the label shows it.

3. Sampling

Samples taken from the line or from a case for quality control physically leave the hierarchy. If they stay in the record, the receiver expects products that are not in the case.

What helps: take samples at a station by scanning; the pack status changes to "sample" and the pack drops out of the hierarchy.

4. Manual handling

Operators moving packs by hand after a jam, a damaged pack or a line stop is the most common source of drift. Every movement made outside the system invalidates the record.

What helps: set up a rework station where opening a case, removing and adding packs is done by scanning, and every action is written to the audit trail with user and time.

5. The same pack in two cases

On fast lines, a pack read twice, or an old relationship not removed during rework, links one serial number to two parents.

What helps: the software enforces "every child has exactly one parent" at database level; a second assignment is rejected with a warning.

6. Pallet breakdown and re-palletizing

When a pallet is split in the warehouse and its cases are moved to other pallets, a pallet record that is not updated makes the shipping notice show the old content.

What helps: breaking down and building pallets is done by scanning too; a new pallet gets a new SSCC, and an old SSCC is never reused.

Print the label last

If the case label is printed before the content is final, a gap opens between label and content. In a good flow the case is filled, its content is verified, and only then is the label printed and scanned to match it with the record. You can verify SSCC check digits with the check digit calculator and review overall line readiness with the serialization readiness checklist. If you want to review the aggregation flow on your current line together, get in touch.

The checks below are the ones we run at the start of every project on wind farm and rotating equipment data.

1. Timestamps

The first question is which time zone a timestamp belongs to, and whether it marks the start or the end of the averaging interval. In data recorded in local time, one hour appears twice or not at all when daylight saving time changes. Data from different systems (SCADA, alarm logs, maintenance work orders) should all be converted to UTC before they are joined.

2. Gaps

A communication outage deletes data; some systems fill the gap with zeros or with the last value. A power record filled with zeros tells the model "the turbine produced nothing". A gap should stay a gap, and coverage should be reported per channel.

3. Frozen values

A faulty or disconnected sensor can repeat the same value for hours. Values that do not change at all over a given period should be flagged. This matters most for temperature and vibration channels: a frozen temperature hides real heating.

4. Physically impossible values

A negative wind speed, a direction above 360 degrees, output far above rated power, or a bearing temperature below ambient are data errors. Define physical lower and upper limits for every channel and flag the records that exceed them.

5. Curtailment, maintenance and fault periods

A normal behaviour model should learn from periods when the machine runs healthy and unconstrained. If grid curtailment, planned maintenance, icing and fault stops stay in the training data, the model treats them as "normal" and misses a real deviation. These periods should be derived from status codes and alarm logs and flagged.

6. Sensor replacement and level shifts

When a sensor is replaced or recalibrated, the measured level can shift suddenly, and the model mistakes it for degradation. Sudden level changes that maintenance records do not explain deserve a separate look.

Flag instead of delete

Rather than deleting bad records, adding a flag that says why each record is questionable has two benefits: clean windows can be selected for training, and loss calculations can state plainly which part of the data could not be assessed. We describe our power forecasting and loss study on an open wind farm dataset in our case study, and how to proceed without labelled failure data in this note. You can run most of these checks on your own CSV file, without uploading it, with our SCADA data quality check. For a first assessment with your own data, get in touch.

1. What does the scanner return?

Most scanners type the decoded content as plain text, like a keyboard. Two things matter in that text. First, some scanners prepend a symbology identifier to the content: ]d2 for GS1 DataMatrix, ]C1 for GS1-128. This prefix is not data and must be removed before parsing. Second, the FNC1 character that separates fields (ASCII 29, "GS") is invisible on screen; some scanners do not transmit it at all, others replace it with another character. Do not build parsing software without knowing how the scanner is configured here.

2. Split the raw text into fields

An example content: 0109504000059118 17271231 10LOT42 [GS] 21A1B2C3 (written with spaces for readability; in reality it is contiguous). Parsing works by reading the application identifier (AI) at the start of each field:

• (01) GTIN: fixed 14 digits
• (17) expiration date: fixed 6 digits, YYMMDD
• (10) batch: variable length, up to 20 characters
• (21) serial number: variable length, up to 20 characters

Fixed-length fields need no separator after them; a variable-length field ends with a separator unless it comes last. In the example the batch (10) is not last, so a GS follows it; the serial number (21) is last.

3. Calculate the GTIN check digit by hand

The last digit (8) of the 14-digit GTIN 09504000059118 is the check digit. The calculation: multiply the first 13 digits, from right to left, alternately by 3 and 1 (the rightmost by 3), add them up, and the number that brings the total up to the next multiple of ten is the check digit. In the example the sum is 72, the next multiple of ten is 80, the difference is 8: the code is correct. With a 7 the symbol would still scan, but the GTIN would be invalid.

4. Check the date and the separators

• The month under (17) must be 01-12. Day 00 means "last day of the month"; does your system handle that explicitly?
• 271231 in the example is 31 December 2027. The same digits written out of a DD.MM.YY habit would give a valid but wrong date.
• If there is no separator after a variable field, the date and batch get mixed into the serial number. A field longer than 20 characters, or an unexpected "17" sequence inside the serial number, is the symptom.

5. Keep readability and correctness apart

The print quality of the symbol (contrast, module size, quiet zone) is one problem; the correctness of the data is another. They are tested separately. Print quality needs a verifier device; for the data, the steps above are enough and can be automated in software for every pack.

Try it with the tool

Paste the content into our GS1 barcode decoder: it splits the fields and validates the check digit and the date. For the check digit alone there is the check digit calculator, and for field definitions the application identifier dictionary. The most common errors on the line have their own note: Five common errors in pharma serialization codes. To set up validation on your line, get in touch.

Three factors

OEE = availability × performance × quality.

• Availability = run time / planned production time
• Performance = (ideal cycle time × total pieces) / run time
• Quality = good pieces / total pieces

Example

The shift is 480 minutes with a 30-minute planned break, so planned production time is 450 minutes. Unplanned stops total 45 minutes; run time is 405 minutes. The part has an ideal cycle time of 0.5 minutes (30 seconds); 700 pieces came out, 21 of them scrap, 679 good.

• Availability: 405 / 450 = 90.0%
• Performance: 0.5 × 700 / 405 = 86.4%
• Quality: 679 / 700 = 97.0%
• OEE: 0.900 × 0.864 × 0.970 = 75.4%

The largest loss shows up in performance (about 13.6%): the machine runs slowly or with short stops while it is "running". Someone who looks only at stop records misses that.

Six common mistakes

• **Counting planned breaks as losses.** Availability is calculated against planned production time. A calculation that puts calendar time (24 hours) in the denominator is a different measure (TEEP); do not mix the two.
• **Using a target cycle time instead of the ideal one.** The ideal cycle time is the design or proven best speed. If you enter today's average speed as "ideal", performance always comes out near 100% and the loss disappears.
• **Counting reworked parts as good.** A part that is not right the first time is a quality loss, even if it is salvaged later.
• **Not recording short stops.** Stops under a minute are usually forgotten in hand-kept records; the loss is pushed into performance, the wrong place. Decide the stop threshold up front.
• **Averaging OEE values.** Adding the OEE of three machines and dividing by three ignores run times. Sum the times and counts first, then calculate the ratios.
• **Burying performance above 100%.** If performance goes above 100, the ideal cycle time is defined wrongly; find the cause instead of clipping the result.

After the number

OEE is a starting point, not a diagnosis. Go deeper in the factor where the loss is: a Pareto of causes for stops, the cycle time distribution for performance, scrap causes for quality. Reading a loss waterfall tells you more than a single OEE for a line.

Enter your own shift figures into the OEE calculator to see the breakdown above in your browser; to rank stop causes there is the unplanned downtime Pareto analysis, and for the money side the unplanned downtime cost tool. To set up OEE measurement on your line, get in touch.

Where do the control limits come from?

In an I-MR chart for individual measurements, the limits are calculated from the process's own data. The absolute difference between two consecutive measurements is the moving range (MR); call its mean MR-bar. The centre line is the mean, and the limits are the mean ± 2.66 × MR-bar (2.66 = 3 / 1.128). The standard deviation estimate is MR-bar / 1.128.

Example: ten measurements: 10.02 · 10.05 · 9.98 · 10.03 · 10.01 · 10.04 · 9.99 · 10.02 · 10.06 · 10.00. The mean is 10.020; MR-bar = 0.0422 (total difference 0.38 divided by 9). The limits are 10.020 ± 2.66 × 0.0422: upper 10.132, lower 9.908. The sigma estimate is 0.0422 / 1.128 = 0.0374. (Ten points are only to show the method; a real limit calculation needs at least 20-25 stable measurements.)

When does it alarm?

Rule 1: one point falls outside the 3-sigma limit. In a normal distribution, even while the process is stable, the probability of a point exceeding this limit is about 0.27%; so on average one false alarm is expected every 370 measurements. To catch small shifts the Nelson rules also look at patterns:

• 9 points in a row on the same side of the centre: the mean has shifted.
• 6 points in a row steadily rising or falling: there is a trend, often wear.
• 14 points in a row alternating up and down: two sources may be mixed.
• 2 of 3 points on the same side beyond 2 sigma: an early sign of a shift.

As the number of rules grows, detection speeds up but false alarms also increase; you need not apply all of them to every process.

A control limit is not a specification limit

Control limits say what the process does, specification limits what the customer wants. In the same example let the lower specification limit be 9.90 and the upper 10.10. Cp = (10.10 − 9.90) / (6 × 0.0374) = 0.89; Cpk = min(10.10 − 10.02; 10.02 − 9.90) / (3 × 0.0374) = 0.08 / 0.1123 = 0.71. Even though all ten measurements are within specification, the process is not capable, because its mean is close to the upper limit and its spread is wide; with the normal-distribution assumption the estimated defect rate is about 1.7%. Cp reflects the spread, and Cpk reflects the spread together with how far the mean sits off centre.

Common mistakes

• **Drawing the specification limit on the control chart.** It reflects what is wanted, not the natural behaviour of the process; control limits must be calculated separately.
• **Calculating Cpk on an unstable process.** Bring it under control first; otherwise Cpk has no meaning.
• **Not keeping the data in time order.** The moving range depends on order; shuffled data distorts the limits.
• **Recalculating limits at every alarm.** Limits come from a stable period; if there is a shift, the cause is investigated, the limit is not moved.
• **Copying a Cpk target blindly.** The accepted level varies with the customer, the sector and the contract.
• **Assuming a normal distribution.** For one-sided or skewed data the ppm estimate can mislead.

Try it with the tools

Paste your own measurements into the control chart (SPC) tool: you get the I and MR charts, the limits and the Nelson rules that were violated. For Cp, Cpk, Pp, Ppk and a ppm estimate against your specification limits there is the Cp / Cpk capability calculator. To set up quality monitoring in your process, get in touch.

1. A missing separator after the serial number

In a GS1 code the GTIN (01) and the expiration date (17) have a fixed length, while the serial number (21) and the batch (10) are variable-length. Unless a variable field comes last, it must be followed by a separator (FNC1, ASCII 29). Without it, the scanner reads the date and batch that follow as part of the serial number. The code is printed and read — but read wrongly.

Prevention: fix the field order in the printer template; the verification camera should parse the printed content field by field instead of only checking "read / not read".

2. A GTIN with a wrong check digit

The last digit of a GTIN is a check digit computed from the others. A GTIN typed into master data by hand, or converted incorrectly from 13 to 14 digits, is printed wrongly on every pack on the line. Because the error starts in the data, not in the symbol, the camera reports "read" while the code is invalid.

Prevention: software should validate the check digit when the GTIN is entered into master data and when a work order is opened.

3. Date format confusion

The expiration date uses YYMMDD: year, month, day. A date entered out of DD.MM.YY habit can turn into a valid but wrong date in the symbol. Day "00" means the last day of the month, which causes inconsistencies between systems that do not handle it explicitly.

Prevention: take the date automatically from the work order instead of having operators type it; read the printed date back and compare it with the work order.

4. Duplicate serial numbers

The same serial number printed on two packs usually happens when a line is restarted or two lines share the same number pool. A duplicate code causes problems in reporting and breaks the traceability of the product in the field.

Prevention: serial numbers should come from a central, collision-free generator; printed and rejected numbers should be recorded permanently and never reused.

5. Characters outside the character set

GS1 alphanumeric fields use a limited character set: accented letters and spaces are not part of it. An accented letter or a space in a batch number violates the GS1 rules; depending on the scanner and system, the code is rejected or misread.

Prevention: define the batch and serial number format as a rule in master data and check it when the work order is opened.

Quick check

You can check the content of a code taken from the line in your browser with our GS1 barcode decoder: it splits the fields, validates the check digit and the date, and checks that the four serialization fields are present. The lasting fix is to run these checks on the line itself, for every pack.

Learn what normal looks like first

The first step is to model the machine's normal behavior, not its failures. Four to eight weeks of vibration, temperature, current and SCADA/PLC records show how a machine behaves under different loads and conditions. Unsupervised methods such as Isolation Forest or autoencoders learn this "normal envelope"; as new measurements move away from it, the health score drops.

The most time-consuming part is not the model but the data: separating downtime, repairing sensor dropouts and telling apart the operating modes of the same machine (idle, part load, full load).

Make alarms meaningful

A health score on its own tells the maintenance team little. The signal and frequency in which a deviation starts point to a physical fault class: bearing, gear, alignment, imbalance or electrical. This classification turns "machine 7 is abnormal" into "machine 7, possible bearing damage" and sends the right team with the right part.

Collect labels along the way

Every alarm should be closed with a technician's finding: was there really a problem, and what was it? Once these findings are written back to the model, the system produces its own labeled data within a few months. Labels become an output of the process, not a precondition.

Show the uncertainty

A remaining-life or output forecast given as a single number creates either too much confidence or too little. Methods such as conformal prediction intervals put next to each forecast the range in which the actual value falls with a stated probability. The maintenance planner then sees the "earliest" and "latest" scenarios together.

Start small, measure

A single line or a group of similar machines is enough for a first pilot. Two things need measuring: how well alarms match technician findings, and how unplanned downtime changes. We have shared how we tested our approach on an open wind farm dataset, including forecast error and interval coverage, on our case study page.

To get a rough idea of what a pilot could be worth, the downtime cost calculator estimates your annual downtime cost and potential savings, and the SCADA data quality check shows whether your data is ready for modelling.

This article summarizes a software team's perspective; it is not legal or regulatory advice. Whether a system complies is assessed within the organization's own validation process.

What should the audit trail record?

Section 11.10(e) of Part 11 requires secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify or delete electronic records. In practice, each event stores:

• who: a unique user identity
• when: server time, with the time zone stated
• what: create, modify or delete
• which record and which field
• the old value and the new value
• the reason for the change (expected in GMP processes, e.g. by EU GMP Annex 11)

Earlier information must not be obscured

The same section requires that record changes do not obscure previously recorded information. In design this becomes two decisions: records are never physically deleted but flagged as deleted (soft delete), and changes are not overwritten but added as new versions. The audit trail itself must be immutable: no application user, administrators included, should be able to edit an audit entry.

Retention and access

The audit trail must be retained at least as long as the electronic record it covers and be available for review and copying during an inspection. That means tying audit records to the same backup and archive policy as the primary data and providing a readable export (PDF or CSV).

Access control and electronic signatures

An audit trail loses its meaning in a system with weak authentication. Part 11 requires limiting system access to authorized individuals (11.10(d)), showing the signer's name, the date and time and the meaning of the signature (such as "approved" or "reviewed") in electronic signatures (11.50), and linking signatures to their records (11.70). Each electronic signature must belong to one individual only (11.100), which is why shared accounts are not acceptable.

A checklist for the software side

• A unique account per user, role-based permissions
• Audit entries generated server-side and not editable from within the application
• Old and new value, a reason field
• Soft delete and record versioning
• Name, date-time and meaning in electronic signatures
• Audit trail backed up with the records and exportable
• Traceable requirement–test mapping for validation documents

We build this structure into the design of our serialization and laboratory software from the start. If you would like to review the audit trail of an existing system together, get in touch.

What do the standards do?

The ISO 10816 series has been replaced by the ISO 20816 series. For rotating machines, it divides the broadband vibration severity measured on structures (mostly velocity, RMS) into four zones according to machine type, power and foundation stiffness: A is the level of a newly commissioned machine, B is suitable for long-term operation, C is limited-duration operation, D is risk of damage. The zone limits change with the machine group, so there is no single "safe mm/s" figure. Read the table from the standard; do not guess.

The standard is not enough: baseline and trend

The zone assessment looks at the absolute level. For early warning, relative change is often more valuable: the level measured on the same machine, at the same point, under the same operating condition while it is healthy is the baseline. A clear rise against the baseline shows that something has changed even while the machine is still in zone B. Set alarm thresholds using both yardsticks: the standard zone (absolute limit) and a multiple of the baseline or a slope (relative limit). Choose the multiples for your machine and experience; an "example" multiplier is not a standard.

Units: acceleration, velocity, displacement

The same vibration is expressed in three units, and they convert into each other by frequency. For a sine, peak velocity = peak acceleration / (2πf). Example: for a peak acceleration of 0.5 g (0.5 × 9.81 = 4.905 m/s²) at 100 Hz, peak velocity is 4.905 / 628.3 = 7.81 mm/s, and RMS velocity, dividing that by √2, is 5.52 mm/s. Because a real signal is not single-frequency, this conversion is valid only for one component; for broadband, velocity comes from measuring velocity directly or integrating the signal.

Common mistakes when setting alarms

• **Changing the measurement point and direction.** Mounting the sensor somewhere else changes the level. Mark the points and keep the same direction and mounting method.
• **Ignoring the operating condition.** When load and speed change, vibration changes; compare data under similar conditions.
• **Alarming on a single measurement.** A momentary spike (impact, measurement error) produces a false alarm. Require it to persist over several consecutive measurements.
• **Looking only at the overall level.** Bearing damage barely moves the overall level in its early stage; you need a high-frequency band or spectrum detail. For spectra, pay attention to the measurement settings (sampling, window, resolution).
• **Not defining the action after an alarm.** What does the "alarm" trigger? Inspection, lubrication, re-measurement, a planned stop: write the action down in advance for each threshold.

Try it with the tools

You can place a velocity value you measured into a zone for your machine group in the vibration severity evaluator and compare it with your baseline; the limits in the tool are for illustration, and what binds you is the standard and the manufacturer's document. For unit conversion there is the vibration unit converter, for spectrum settings the FFT measurement setup. How to proceed without labelled failure data is in this note. For setting up vibration monitoring, get in touch.

1. Know the logging interval first

The only input to a coverage calculation is the expected record count, and that comes from the logging interval. With 10-minute averages you expect 144 records a day, 4,320 over 30 days. If the file has 4,104 rows, coverage is 4,104 / 4,320 = 95.0%, so 216 records (about 36 hours) are missing. Assuming the wrong interval ruins coverage from the start: read hourly data as 10-minute data and it looks 100% "missing".

2. Gaps: how long becomes a problem?

A single missing record is unimportant in most analyses; a long outage matters. Think of the threshold as a multiple of the logging interval: for example, in 10-minute data a spacing larger than 1.5 times the interval between two consecutive records can count as a gap, but a longer threshold (say, several hours) can be chosen for a "problem gap". Set the threshold by use: a short one for instant alarms, a longer gap is acceptable for daily energy calculations. Never fill a gap with zero or with the last value.

3. Frozen values: window length

A frozen value is the value staying exactly the same over N consecutive records. Choose N by the nature of the signal. On a continuously varying channel such as wind speed or vibration, 6 identical values in 10-minute data (1 hour) is suspicious. On the other hand, the power of a stopped machine or a fixed setpoint may legitimately be constant: there a frozen value is a state, not an error. So set the threshold per channel and assess stopped periods separately.

4. Out of range: physical limits

Derive the limit from physics, not from the data itself. Examples: direction 0-360 degrees, relative humidity 0-100, speed cannot be negative. For fields like temperature, keep the limit wide and catch only impossible values (a bearing temperature below ambient, for instance, is outside this and is a machine-specific rule). Values that are physically possible but unusual are not errors but statistical outliers; they are examined in a separate step.

5. How to read the result

• Look at coverage per channel and the share of problem records, not at the error count.
• If gaps, freezing and out-of-range values appear together on one channel, a sensor or communication problem is likely; compare with the maintenance records.
• Flag, do not delete: a flag stating why a record is questionable lets you pick training windows and report losses honestly.

Try it with the tool

Give your own CSV file to the SCADA data quality check: the file is not uploaded to a server, it is processed in your browser. For timestamp problems the timestamp converter helps. For a first assessment with your own data, get in touch.

What does the sample size depend on?

Four quantities determine one another:

• **The current rate** (for example a 5% conversion rate).
• **The smallest difference you want to catch** (for example from 5% to 6%).
• **The significance level** (usually 5%, two-sided): the risk of wrongly saying "there is a difference" when there is none.
• **The power** (usually 80%): the probability of catching a difference when it really exists.

Tightening any one of them enlarges the sample. With the two-proportion z-test approach, examples:

• 5% → 6% (a 20% relative lift): about 8,158 users per group, about 16,300 in total for two groups
• 5% → 7%: about 2,213 per group
• 5% → 5.5% (a 10% relative lift): about 31,234 per group

When the difference is halved, the sample grows about fourfold: the sample is inversely proportional to the square of the difference. That is why measuring small improvements is expensive.

Five common misconceptions

• **Stopping the test when it turns significant.** Looking at the result continuously and stopping at the first significant p-value raises the false-positive rate. Write down the sample size and duration beforehand and do not decide before reaching them (or use sequential testing methods).
• **Trying many metrics or segments.** Out of twenty metrics, one is expected to come out significant by chance. Fix the primary metric in advance and treat the others as exploration.
• **Skipping the full weekly cycle.** Weekday and weekend behaviour differ. Run the test for at least one, preferably two full weeks.
• **Confusing significance with effect size.** In a very large sample even a trivial difference turns significant; look at the confidence interval and the business value.
• **Not noticing a broken split.** If the share of users between groups deviates from plan (for example 52-48 instead of 50-50), there may be an assignment error; the result should not be interpreted without this check.

Survey samples: a short note

In surveys the same logic works with different quantities: margin of error, confidence level and population. For 95% confidence and a ±5% margin of error, in the worst case (proportion 50%) the sample needed for an infinite population is 384.15, which rounds up to 385. If the population is 2,000 people, the finite population correction brings it down to 323. With a 30% response rate you must invite 323 / 0.30 ≈ 1,077 people. Whether respondents represent the whole population (response bias) is a separate problem; sample size does not solve it.

Try it with the tools

You can calculate the needed sample and the significance of a result in the A/B test sample size and significance tool: the two-proportion z-test, p-value, confidence interval and relative lift come out in your browser. For surveys there is the survey sample size tool, and for differences in means the t-test calculator. To review your experiment design together, get in touch.

1. Day of month and day of week combine with OR

Reading "0 9 1 * 1" as "09:00 if the 1st is a Monday" is a common misreading. When both fields are restricted, classic (Vixie) cron combines them with OR: the job runs on the 1st and also every Monday. If one of them is a star, the logic goes back to AND. For a condition like "the first Monday of the month" the expression alone is not enough; the job has to check today's date itself.

2. A step value resets at the top of the hour

"*/7 * * * *" looks like every seven minutes; in reality the minutes are 0, 7, 14, ... 56, and then 0 again at the top of the hour. So the gap after 56 is 4 minutes. Steps that do not divide 60 (7, 8, 25...) run unevenly. If you truly need an even interval, pick a step that divides 60 (5, 10, 15, 20, 30) or build the scheduler on a "since last run" basis.

3. Months without a 31st

"0 0 31 * *" does not run every month, only in the seven months that have 31 days. For "month end", a safe day such as the 28th is usually chosen, or the job runs every day and checks whether tomorrow is the 1st. In February the 30th and 31st never exist, and the 29th only in leap years.

4. Time zone: what does the server say?

The time zone of a cron expression is the time zone of the environment the job runs in, which in most cloud environments is UTC. UTC 06:00 is 09:00 in Türkiye (UTC+3, no daylight saving). For "every morning at 09:00" on a UTC server the expression must be "0 6 * * *". When the environment changes (from a local machine to the cloud) the time zone changes too and the job shifts by three hours. So note next to the expression which time zone it was written in.

5. Daylight saving changes

In a time zone with daylight saving, one hour does not exist at the spring change: in Germany, for example, on the last Sunday of March local time jumps from 02:00 to 03:00, and "30 2 * * *" may not run that day. In autumn one hour happens twice and the same job may run twice. Behaviour depends on the scheduler. Countermeasure: schedule critical jobs in UTC, or write the job so that running it again does no harm (idempotent).

6. Other systems' syntax

Quartz and similar tools use six or seven fields with a seconds field, and special characters such as "?", "L" and "W". Pasted into standard cron, such an expression is invalid or means something else. For day of week, both 0 and 7 mean Sunday; names (MON, JAN) may not be supported everywhere.

See it before you run it

Type the expression into the cron expression explainer: it explains it in plain language, shows the next 10 run times for the time zone you choose and warns about traps like the OR rule. To convert timestamps there is the timestamp converter, and for retry behaviour the API retry simulator. To review your integration schedule, get in touch.

1. A JWT is not encrypted

The header and payload of a signed JWT are only base64url-encoded; anyone can read them. Do not put passwords, identity numbers or confidential business data in the payload. If confidentiality is needed, use the encrypted form (JWE), or carry only a reference number in the token and keep the data on the server.

2. Decoding is not verifying

Decoding the payload and reading "user: ayse, role: admin" does not show that the token is genuine. Trust arises only after the signature is verified with the key. Server code that only decodes and trusts the fields lets anyone write their own token.

3. "alg": "none" and algorithm confusion

The alg field in the header comes from the token itself; an attacker can change it. The verifier must take the algorithm to accept from its own configuration, not from the header. "none" must never be accepted, and a token signed with a public key (RS) must not be "verified" with HS by using that same key as a secret.

4. Not checking expiry and audience fields

• If the exp (expiry) field is not checked, the token stays valid forever.
• If iss (issuer) and aud (audience) are not checked, a token issued for another service also passes on your API.
• nbf (not before) and clock skew: a few minutes of tolerance between servers is enough, not hours.

5. A long-lived access token

An access token should be short-lived (minutes), with a separate refresh token to extend the session. A stolen long-lived token can be used with full authority until the theft is noticed.

6. Where it is stored

A token in localStorage in the browser falls into the hands of any script that leaks into the page (XSS). In a cookie with the HttpOnly and Secure flags and a suitable SameSite setting, it cannot be read by scripts; but if you use cookies you must also think about CSRF. No option is sufficient alone.

7. Not being able to revoke

A JWT is a self-contained token; to cancel it before expiry the server needs an extra mechanism (a deny list, a session version, a short lifetime). The token of a user who logs out or loses authorisation stays valid until it expires; accept that in the design or close it.

8. A weak HMAC key

With shared-key algorithms such as HS256, a guessable or short key can be cracked by offline trial. The key should be randomly generated, long enough and stored apart from the code.

How to use the tool

You can open a token in your browser with the JWT decoder to see the header, payload, time fields and weak settings; the token is not sent anywhere. The tool decodes, it does not verify: real verification must be done on your server with the key. To try signature logic there is the webhook HMAC signature verifier, and for keys the password strength and entropy calculator. To review your API security, get in touch.

1. VA and W are not the same

UPS units are quoted in two values, VA (apparent power) and W (real power). The power factor lies between them: W = VA × power factor. For example, a UPS rated 1000 VA with a power factor of 0.9 carries at most 900 W. The power factor varies from model to model; look at the real power rating in the catalogue. On the load side it is the same: if a server's power is stated in W you need not convert it to VA, but the UPS's W limit must be larger than the load total.

2. Add up the load properly

Adding the nameplate (maximum) power of the devices gives an exaggerated result; measuring the real consumption or reading it with a power meter is more accurate. Still, account for start-up loads (disks spinning up, cooling fans) and devices to be added later. Leaving a margin instead of running the UPS at its full rated power is a common internal yardstick; set the margin according to your own policy.

3. Runtime: energy divided by power

The simple approach goes through the steps below. Example: load 300 W; two 12 V, 9 Ah batteries in series (24 V, 9 Ah).

• Nominal energy: 24 V × 9 Ah = 216 Wh
• With 90% inverter efficiency, power drawn from the battery: 300 / 0.9 = 333.3 W
• Battery current: 333.3 / 24 = 13.9 A
• The whole battery cannot be used: with 80% usable depth and an 80% ageing or temperature correction, usable capacity is 9 × 0.8 × 0.8 = 5.76 Ah
• Time: 5.76 / 13.9 = 0.415 hours, about 24.9 minutes

Shorter than you expected? That is normal: only about half of the nominal 216 Wh is actually usable.

4. Working backwards from a target time

You can turn this around. If 30 minutes is wanted for the same load, the usable capacity needed is 13.9 A × 0.5 h = 6.94 Ah, and in nominal terms 6.94 / 0.64 = 10.85 Ah; so a battery string of about 11 Ah or more is needed. The next standard size up must be chosen.

5. Limits of the calculation

• **The load is not constant.** Runtime lengthens non-linearly as the load falls; at high current the battery delivers less capacity (the Peukert effect). The constant-power assumption is approximate.
• **Batteries age.** A battery a few years old has less capacity than at the start; a hot environment shortens its life too.
• **The manufacturer's curve is what counts.** The calculation is for a preliminary decision; for the exact time use the manufacturer's load-runtime table.
• **End voltage.** The UPS shuts down when it drops below a certain voltage; this "depth" must be consistent with the DoD you entered in the calculation.

Use the tool

Enter your own load, battery and target time into the UPS backup runtime calculator: it calculates runtime from VA or W, power factor, inverter efficiency, an ageing margin and an optional Peukert exponent, shows sensitivity when the load changes, and in reverse mode gives the capacity needed. For the cooling load of the whole server room there is the server room power and cooling calculation. To review your backup power design, get in touch.

Address count from the prefix

A /n prefix says that the first n of the 32 bits identify the network. The block holds 2^(32-n) addresses:

• /24: 256 addresses (usually 254 usable for clients)
• /23: 512 addresses
• /22: 1,024 addresses

In classic networks the first address is the network address and the last is the broadcast address, so the usable count is two fewer (2 of the 4 addresses in a /30; /31 is a special exception for point-to-point links). Cloud providers reserve addresses of their own as well; the number varies by provider, so plan according to its documentation.

Alignment: a block starts at a multiple of its own size

A /24 block starts at an address that is a multiple of 256, a /23 at a multiple of 512. That is why 10.0.0.0/24 and 10.0.1.0/24 merge into 10.0.0.0/23: third byte 0 and 1 exactly fill a 512-address block. By contrast 10.0.1.0/24 and 10.0.2.0/24 look adjacent, but because 10.0.1.0 does not start at an even third byte they do not fit into a single /23; if you try to summarise them as one block you include addresses in between and around them. Four consecutive /24s (10.0.0.0 to 10.0.3.0) can be summarised as 10.0.0.0/22.

Why summarisation matters

Keeping a single line in the routing table instead of dozens of branch networks shrinks the table and hides faults. But if the summary block also covers addresses that are not yours, traffic can go to the wrong place. Summarisation is safe only for blocks that are truly contiguous and aligned; plan by splitting into large, aligned blocks from the start (a /24 per branch, a /20 per region, for example).

Overlap checking

Two blocks overlap if the address range of one intersects the other; they also overlap if one block lies inside the other. Example: 10.20.0.0/16 and 10.20.8.0/21 overlap, because the /21 covers addresses with third byte 8-15, which are inside the /16. Overlap appears most often when:

• The company network and a home or guest network use the same default block, so routes get mixed up over the VPN.
• Two companies merge and both use 10.0.0.0/16.
• A cloud virtual network and the local network were built in the same block and are to be connected.

A planning pattern

• Place the largest requirement first, then work down to the small ones (VLSM).
• Leave growth room in every block: twice today's need is a common yardstick.
• Avoid common blocks such as the default 192.168.0.0/24 and 10.0.0.0/24 so as not to overlap with networks that may connect in future (partners, cloud).
• Write the usage in a table: block, purpose, owner, date.

Try it with the tools

For an address and prefix, see the network, broadcast, first-last address and host count with the IP subnet and CIDR calculator. To summarise several blocks into one or to check overlap, use CIDR summarisation and merging; for IPv6 there is the IPv6 subnet calculator. To review your network and cloud address plan together, get in touch.