By the end of this chapter you can

• Say what a CMMS does from request to reliability figure, and which tools the module replaces.
• Name what the module leaves to M11 and M12, and what stays outside the course entirely.
• Explain why maintenance attributes hang on the spine's equipment and not on a separate asset list.
• Name the standards the module is built against and what each is used for.

What the module does

Maintenance (CMMS) runs maintenance from the first request to the reliability figure that shows whether the programme works. It keeps one asset register on the shared ISA-95 equipment hierarchy, work orders with ISO 14224 failure coding, preventive maintenance triggered by time, meters or condition, spare parts for maintenance, repair and operations (MRO), calibration records, and technicians who complete work on a phone with no signal. It then measures the result with the maintenance KPIs of SMRP and EN 15341 ^[8].

The module specification names the tools it replaces: IBM Maximo, Rockwell Fiix, UpKeep, MaintainX, Limble, Fluke eMaint, SAP PM and HxGN EAM. Four of them (Fiix, MaintainX, Limble and UpKeep) export assets, PMs, work orders and parts as CSV or through an API, which is what makes the cutover in chapter 4 possible ^[5][6][7]. CMMS (computerised maintenance management system) and EAM (enterprise asset management) describe the same family of tools; EAM leans toward the whole life of an asset.

What is in, and what is not

The module is wide enough to replace the tools above and narrow enough to leave permits, stock valuation and predictive models to the modules built for them.

• In: a maintenance profile on spine equipment (criticality, ISO 14224 class, warranty, costs); work requests from QR, mobile, shift log, forms and SCADA conditions; the work order lifecycle with planning, scheduling, execution and closeout coding; preventive, meter-based and condition-based maintenance with forecasting; job plans, crafts, labour, parts, tools and permit flags; MRO spares and reorder points; calibration records; reliability analytics.
• Out: permit issuance and LOTO procedure ownership (M11; the CMMS only references the permit); general inventory valuation and purchasing (M12; spare-part stock movements are posted to M12's ledger); predictive models and asset performance management (catalogue Wave 4; they feed condition triggers here).

Twelve capabilities in three tiers

Each capability carries a tier. MVP must exist for a business to cancel its incumbent subscription with confidence. STD is parity with mainstream tools, what a buyer expects in a demo. BIC marks best-in-class differences, here AI that suggests failure codes and PM intervals for a person to approve.

MVP and STD are required for the course. The BIC capability is advanced work; this course meets it only where a later session asks for an AI suggestion that a person approves.

One asset tree, not two

Maintenance needs a list of what it maintains. The production side already has one: the equipment hierarchy on the shared spine, built on the ISA-95 model. ISO 14224 defines a taxonomy for equipment in nine levels, from industry down to the part, and shows where maintenance data attaches ^[1][3]. If the CMMS keeps its own asset list, the two drift: the same pump is counted twice, or not at all, and no figure built on either list can be trusted.

The standards, and what each is used for

References

1. Accendo Reliability: setting up the asset hierarchy (ISO 14224 levels). https://accendoreliability.com/setup-asset-hierarchy/
2. Reliability Magazine: how to build an asset hierarchy in a CMMS. https://reliamag.com/guides/how-to-build-asset-hierarchy-cmms/
3. ISO 14224:2016 Petroleum, petrochemical and natural gas industries: collection and exchange of reliability and maintenance data for equipment. https://www.iso.org/standard/64076.html
4. ISO 55001:2014 Asset management: management systems, requirements. https://www.iso.org/standard/55089.html
5. Limble: Fiix alternatives and core CMMS features. https://limblecmms.com/?p=26572
6. EZO: EZO against Fiix and Limble. https://ezo.io/ezo-cmms/blog/ezo-vs-fiix-vs-limble/
7. GetApp: MaintainX against Limble (modules). https://www.getapp.ca/compare/117239/2049215/getmaintainx/vs/limble-cmms
8. SMRP: Society for Maintenance and Reliability Professionals, maintenance and reliability metrics. https://smrp.org/

By the end of this chapter you can

• Name the fifteen cmms_ tables, group them, and say which spine tables they point at.
• Read the column tables: type, required, and allowed values.
• Say why some links are plain uuid columns with no foreign key.
• Name the five roles and the five screens, and say which role uses which screen.

Fifteen tables on the shared spine

Every table starts with the standard columns every platform table has: id, tenant_id, created_at, created_by, updated_at, updated_by, row_version, archived_at and ext. The module has no people table, item table, site list or file store of its own: it points at core_equipment, core_equipment_class, core_person, core_item, core_storage_location, core_uom, core_data_tag, core_reason_code, core_attachment and core_e_signature. Its own tables share the prefix cmms_. Pointing at core_equipment keeps one asset hierarchy for production and maintenance, built on the levels that ISO 14224 describes ^[1][2][3]. Together the tables cover the core features a CMMS product offers: assets, work orders, preventive maintenance, parts and mobile work ^[5].

The tables below are the full definition: every column the module adds to the standard ones. Types are written as in the specification. text, int, num (a decimal number), bool, date, ts (a timestamp with time zone), uuid and json (jsonb in Postgres) are as usual. money is an amount of money and qty a decimal quantity; both are numeric columns, never text. An arrow means a foreign key to that table, and req means required (not null). Allowed values become check constraints.

Assets, crafts, meters, spares and failure codes

Plans and preventive schedules

Requests, work orders and their results

Rules the schema holds

• Four soft links. permit_ref, procedure_doc_ref, inventory_txn_ref and impact_assessment_ref are plain uuid columns with no foreign key, because the modules they point to (M11, M06, M12, M08) may not be installed yet. Everything else points only at core_ tables and at other cmms_ tables. For exchange with systems outside the platform, the specification names MIMOSA's open models, CCOM and OIIE, as the integration reference ^[4].
• One profile for one machine. equipment_id on cmms_asset_profile is required and unique, so a second profile for the same equipment is refused. core_equipment.status is the master status; the profile's status is mapped to it and a test checks they agree.
• Numbers come from a sequence. request_no and wo_number are unique per tenant and issued from core_number_sequence, not counted by hand.
• One open work order for one schedule. A partial unique index on cmms_work_order (pm_schedule_id) applies only while the status is not completed, closed or cancelled, so the database itself refuses a second open work order for one PM schedule. Chapter 3 relies on it.
• Four failure keys, not one text. The four key columns on cmms_work_order point at cmms_failure_code, whose code_type and equipment_class_id say which list a code belongs to.

Five roles, four machine accounts

Roles are jobs, not names. Each maps to a row in the spine's core_job_role. A person who holds two roles may not approve their own work.

Four machine accounts act with their own login and no person behind them: cmms_pm_engine generates preventive work, cmms_stock_route posts parts to the inventory ledger, cmms_calibration_route records calibration results and raises impact assessments, and cmms_import is used only for the data move in Session 5 and removed in Session 6. Nobody gets delete anywhere: a mistake is a new row, a reversing ledger entry or a status. No role holds a right on core_number_sequence either: request and work order numbers come from a security-definer function, a function that runs with its owner's rights so the caller needs none.

The screens are /maintenance/request (opened by a QR label whose address carries the equipment code), /maintenance/work (the technician's offline list), /maintenance/schedule (the weekly schedule against each craft's capacity), /maintenance/queue (triage, approval and closeout review) and /maintenance/reliability (the dashboard). The module's own routes are /api/maintenance/sync, /api/maintenance/parts and /api/maintenance/calibration.

Exercise · Profile one real asset15 minutes

You need: One machine from the first area you chose in Session 1, its row in your equipment list, and your AI coding agent

Work on paper or in a text file first. Use the machine's real code but no person's name. Leave a field empty when you do not know it; never guess a date or a cost.

1. 1. Find the machine's row in core_equipment (or your equipment list) and write its code. If it is not there, stop and ask the owner of the hierarchy: the module never adds a second list.
2. 2. Choose its criticality, a, b or c, and write one line on why: what happens to safety, output and cost if it stops for a day.
3. 3. Write its ISO 14224 class if you know it, whether it is maintainable, and its status from in_service, standby, out_of_service or retired.
4. 4. Copy the warranty date, purchase cost and replacement cost from a document or invoice only. Write "empty" for any you cannot show.
5. 5. Write the QR address for its label, with the equipment code in it, and list its spare parts, marking which are critical.
6. 6. Ask your agent: "Show me the cmms_asset_profile row for this equipment, then show an insert that must fail: a criticality of x, and a second profile for the same equipment." Read the answer against the column table above.

Outcome: A one-page profile for a real machine, with no invented values, and a row your agent drew that you checked against the column table, plus the two inserts it said the database would refuse.

References

1. Accendo Reliability: setting up the asset hierarchy (ISO 14224 levels). https://accendoreliability.com/setup-asset-hierarchy/
2. Reliability Magazine: how to build an asset hierarchy in a CMMS. https://reliamag.com/guides/how-to-build-asset-hierarchy-cmms/
3. ISO 14224:2016 Petroleum, petrochemical and natural gas industries: collection and exchange of reliability and maintenance data for equipment. https://www.iso.org/standard/64076.html
4. MIMOSA: open standards for asset-management information exchange (CCOM, OIIE). https://www.mimosa.org/
5. Limble: Fiix alternatives and core CMMS features. https://limblecmms.com/?p=26572

By the end of this chapter you can

• Trace a request to a closed work order and name the role that makes each move.
• Explain how calendar, meter, condition and hybrid triggers create exactly one work order, and how floating and fixed schedules differ.
• Say why closeout needs four structured failure keys, and what the LOTO guard refuses.
• Describe how parts and calibration results are recorded and what an out-of-tolerance result starts.

From request to work order

Anyone can raise a work request from a QR label, a phone, a shift log entry, a failed form item or a SCADA condition. A request is one row in cmms_work_request with the status new, the source, who asked and, if known, the equipment and a photo. The maintenance supervisor triages it: accepted, rejected (with the reason in a comment) or duplicate. Each decision tells the requester in the same transaction, and by default the message stays inside the app: texts and email cost whatever your provider charges, so they are switched on only after you have read its price page. The planner then turns an accepted request into a draft work order and marks the request converted, with work_order_id filled in.

The ten statuses

A work order starts as a draft and ends as closed or cancelled. Row-level security cannot see which move a row makes, so one trigger on cmms_work_order holds the rule: it allows only the moves below and refuses every other.

A new row may start only as draft (the planner), as approved (the PM engine, or the supervisor for an emergency breakdown) or, for imported open orders and history in Session 5, in any status before in_progress or as closed (the import account only). Because a right on a table is a right on its whole row, the same trigger also refuses any change to equipment, type, priority, scheduled dates or assignee by anyone but the planner or supervisor.

A trigger on the same table writes the module's events to core_event_outbox. It publishes cmms.work_order.status_changed and cmms.work_order.completed there, and four more triggers write the rest, because core_event_outbox is written only by triggers and no role has a right on it: cmms.work_request.created on insert into cmms_work_request, cmms.pm.generated on insert into cmms_work_order where pm_schedule_id is set, cmms.calibration.out_of_tolerance on insert into cmms_calibration_record with result out_of_tolerance, and cmms.asset.out_of_service on cmms_asset_profile when status becomes out_of_service. It consumes five events from other modules when those modules are installed: shf.log_entry.created (shift handover, M02), frm.response.failed (digital forms, M01), mes.equipment.state_changed (MES, M04), ehs.permit.closed (EHS, M11) and inv.item.stock_below_reorder (inventory, M12). Nothing in this course needs them, so the module works without them.

Two guards: LOTO at the start, coding at the end

Lockout and tagout. A job plan with loto_required true cannot start without a permit reference. The specification enforces that reference in the database when M11 is installed; where it is not, a manual reference is typed instead: the technician enters the number of the paper lockout permit, it is stored in ext as permit_ref_manual, and the start is refused while both it and permit_ref are empty. OSHA's standard on the control of hazardous energy (29 CFR 1910.147) is the reason: a machine must be isolated before it is serviced ^[2]. The permit itself is issued and owned by M11, so the CMMS holds only the soft link, permit_ref. When the EHS module and its ehs_permit table exist, the permit's status must also be active, and the trigger checks that table's existence first so it still runs where the module is not installed.

Measurements are judged by the server. A task measurement outside its lower and upper limit (lsl and usl on the job plan task) is stored as result fail by the server, never by the browser, and a failed task raises a work request. Labour rows take their rate from cmms_craft.hourly_rate on the server, never from the phone.

Closeout coding

When a corrective or predictive work order is closed it must carry four structured keys: how it failed (mode), why (cause), the physical process (mechanism) and what was done (remedy). Each points at a cmms_failure_code of the right code_type, whose equipment class is the equipment's class or empty. ISO 14224 supplies the pick-lists ^[1][4]. The supervisor reviews the coding before closing; a closeout with a code missing is refused.

Preventive maintenance without double work

A cmms_pm_schedule says which job plan runs on which equipment, and what triggers it. One SQL function, cmms_generate_pm(as_of), run by the machine account cmms_pm_engine, finds every active schedule on a maintainable asset that is due at the given time and makes one preventive work order for each, with its tasks. Tests run it with a fixed clock. Scheduled preventive work of this kind is one of the core features every CMMS product offers ^[5]. The engine first rolls forward the schedules whose work order was completed, then generates, so a completed order never leaves its schedule due twice. A forecast function lists the dates each calendar schedule falls due in the next 90 days, so the planner sees the work coming.

Because the database already refuses a second open work order for one schedule, running the engine twice makes one. The seed proves it: on the cycle counter of the second asset, with a next_due_meter of 500, the readings 495, 505 and 512, with the engine run after each, give exactly one open work order, made at 505 and still the only one after 512. The 8000-hour meter on the first asset is not used for this test; it is kept for the MTBF and MTTR check. A cumulative meter that goes down is refused, because a replaced meter needs a new cmms_meter row. Separately, when a reading passes alert_high or falls below alert_low, the engine inserts one work request with source scada, but only while an earlier one is still new or accepted.

Floating or fixed

When a PM work order is completed the engine sets last_completed_at and the next due value. A floating schedule counts the next interval from the day the work was done: 30 days after a PM completed 10 days late, or the meter value at completion plus meter_interval. A fixed schedule counts from the previous due value, adding intervals until the next one is in the future, so a long gap does not create a burst of work orders.

Parts and calibration

Parts go through the ledger. The phone sends an id it made itself, the work order, the item and the quantity. The route, run as cmms_stock_route, for a use checks that the work order is assigned to the caller and is in_progress, or completed and not yet closed (a phone that worked offline sends its parts after its completion entry has arrived; the queue sends each part move to this route after the entry is accepted, with its own id), and for a return checks that the caller holds the maintenance supervisor role and the work order is not cancelled. It inserts the cmms_wo_part row, posts one inv_inventory_transaction from the storage location against the work order, and writes unit_cost and inventory_txn_ref back, all in one transaction. A retry posts once. Parts returned unused are a reversing entry that names the original; the ledger is append-only and a part count is never changed by editing a number in a cmms_ table. Stock at or below reorder_point on cmms_spare_part_link shows on the planner's schedule screen.

Calibration records what the instrument read. A calibration work order has measurement tasks for the as-found points, then the adjustment, then the as-left points. On completion /api/maintenance/calibration, run as cmms_calibration_route, builds as_found and as_left from the results, compares them with the limits copied into tolerance, and inserts one cmms_calibration_record with the result pass, fail, adjusted_pass or out_of_tolerance. The certificate is a core_attachment, and the record's due_at comes from the instrument's calibration schedule, a calendar PM schedule whose work orders are of type calibration. The route refuses a reference standard whose own latest calibration is past its due date, which is the traceability that ISO 10012 and ISO/IEC 17025 ask for ^[3].

Exercise · Run a meter PM and a late PM on paper15 minutes

You need: Paper or a spreadsheet, and your AI coding agent for the last step

Use the seed's numbers: a meter PM every 500 cycles on the second asset's cycle counter with next_due_meter 500, and a calendar PM every 30 days. Nothing here is real data.

1. 1. Write the meter readings 495, 505 and 512 in a column. Beside each, write whether the schedule is due, and how many open preventive work orders exist after that reading.
2. 2. The work order is completed at reading 512. Calculate next_due_meter if the schedule is floating, and if it is fixed. Write both.
3. 3. A calendar PM due on day 30 is completed on day 40. Calculate its next due day if floating, and if fixed. Write both and compare them with the diagram.
4. 4. Decide, for one real PM in your own first area, whether floating or fixed is right, and write the reason in one line.
5. 5. Name the database rule that stops the engine making a second open work order when it runs twice, and the table and column it is on.
6. 6. Ask your agent: "Write a test that runs cmms_generate_pm twice with a fixed clock after reading 505 and counts the open preventive work orders for the schedule." Check that the expected count is one.

Outcome: A filled-in table of three readings and two next-due values (1012 and 1000 cycles; day 70 and day 60), your floating or fixed choice for a real PM, and a test your agent wrote that expects exactly one work order.

References

1. Fabrico: ISO 14224 failure taxonomy codes. https://www.fabrico.io/blog/iso-14224-failure-taxonomy-codes/
2. OSHA: 29 CFR 1910.147, The control of hazardous energy (lockout/tagout). https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.147
3. ISO/IEC 17025:2017 General requirements for the competence of testing and calibration laboratories. https://www.iso.org/standard/66912.html
4. ISO 14224:2016 Petroleum, petrochemical and natural gas industries: collection and exchange of reliability and maintenance data for equipment. https://www.iso.org/standard/64076.html
5. Limble: Fiix alternatives and core CMMS features. https://limblecmms.com/?p=26572

By the end of this chapter you can

• Describe how offline work is queued and synced without loss or duplication, and what happens to a stale status move.
• Define PM compliance, schedule compliance, MTBF, MTTR, planned against reactive, backlog and cost against replacement value.
• Check MTBF and MTTR by hand against the dashboard.
• Plan a cutover from an incumbent CMMS and state the four tests that mean the module is done.

Offline execution

The technician's work screen saves, on sign-in, the technician's assigned work orders, tasks, job plans, pick-lists and spares list to IndexedDB, the browser's own database on the phone, which survives closing the app, with a "last updated" time. Each change is queued with an id the phone made itself using crypto.randomUUID() (a function every modern browser has that makes a random id no other phone will pick), so twenty queued completions are twenty separate records and none can overwrite another. The queue is sent when a connection exists and retried until the server confirms.

• Insert once. The sync route inserts new rows with on conflict (id) do nothing, so a repeated send does nothing the second time.
• Set, never add. A task result or a status move sets a value; setting the same value twice leaves the same result. That property is called idempotent.
• Stale moves are refused. The queue keeps one entry per job holding its moves in order (start, task results, labour, completion), with the row_version the phone saw when it last downloaded the job. The route applies the moves in order in one transaction and checks the version once, against the first move, because each applied move adds one to row_version. It refuses the whole entry when the row has changed in the meantime, for example when a planner cancelled the job, and answers a repeat of an entry it has already applied as done. The refusal is kept and shown, never deleted.
• Two clocks. The phone's own times go in actual_start, actual_end, done_at and started_at; the server's receiving time goes in ext as synced_at.
• Expired sign-in waits. If the sign-in has expired when the phone reconnects, the queue waits for sign-in and loses nothing.

Seven measures

The module's KPIs follow the maintenance metrics of EN 15341 and SMRP ^[1]. Each can be counted from the tables in chapter 2, so a dashboard can be checked against a hand count.

MTBF is mean time between failures, MTTR mean time to repair, and RAV the replacement asset value, which is why replacement_cost sits on the asset profile. Beyond these, the dashboard ranks bad actors (the assets that fail or cost the most) and draws a failure Pareto by equipment class and mode, which only works because the codes are structured.

The check is the point. If the dashboard says 2000 and your hand count of the seed says 2000, the dashboard is right for that data. If they differ, either the query's definition or the data is wrong, and the difference must be explained before anyone trusts the figures on real work. Operating time normally excludes the time the machine was down; the seed takes the running-hours meter's 8000 hours as they are and does not subtract the 20 repair hours, so the figure stays easy to check by hand. On real data, write in your view's definition which you use.

Moving off the old system

Per the module specification, Fiix, MaintainX, Limble and UpKeep export assets, PMs, work orders and parts as CSV or through an API; for any other system, read its own export page ^[2][3][4]. Work orders contain people's names, so keep the export in a private folder outside the repository until you have read what it holds.

1. Count the rows in each file and compare them with the counts you took in Session 1. A truncated file is found now, not after cancellation.
2. Map asset ids to spine equipment codes first, in three outcomes: matched, near match for a person to decide, and no match. Never create a separate maintenance list.
3. Map failure codes: the free way is mapping the most used ones by hand. An AI step is optional and costs what your provider charges; it sends only distinct old texts and the code list, and a person decides each proposal.
4. Import job plans and PM schedules with their old next due dates unchanged, switched off, and dry-run the engine before switching any on, because a burst of overdue work orders is the usual surprise.
5. Load spares without the old on-hand counts, which are usually stale; count the critical spares and load opening stock as ledger adjustments.
6. Import open work orders, then closed work orders as read-only history, with the old numbers kept in ext, and no ledger posting for history.
7. Run old and new side by side for a week, compare the figures, cut over on a date you set, and cancel the old subscription with the saving written from real invoices.

Done means testable

The definition of done is four tests an agent can run, and you should run them yourself. ISO 55001 asks an asset management system to monitor, measure and evaluate its own performance ^[5]; these tests and the seven measures are how this module does it.

• A meter reading crossing a threshold generates exactly one PM work order.
• A LOTO-required work order cannot start without a permit reference (where the permit module is present).
• MTBF and MTTR on the seeded data match a spreadsheet calculation.
• Mobile offline completion of 20 work orders syncs without loss.

In the module's ecosystem, equipment is the shared spine hierarchy, downtime comes from MES equipment-state events, and the activity-based costing of the CivOps core consumes the labour and parts cost recorded here.

Exercise · Check MTBF and MTTR by hand15 minutes

You need: The Session 2 seed (or one asset's closed corrective work orders from your own export), and a spreadsheet

Use the seed first. If you have real closed work orders for one asset, repeat steps 2 to 5 on them afterwards.

1. 1. Export the closed corrective work orders of the seed's first asset to a CSV file: the start, end and repair time of each.
2. 2. Count the failures and write the number. On the seed it is four.
3. 3. Read the running-hours meter at the start and end of the period, and subtract to get the operating hours: 8000 on the seed.
4. 4. Divide operating hours by failures to get MTBF, and total repair hours by repairs to get MTTR. Write both with their units.
5. 5. Open the reliability dashboard as the reliability engineer and compare. They must match: 2000 hours and 5 hours on the seed.
6. 6. Change one repair time in a copy of the CSV and see how MTTR moves, then say in one line why MTBF did not move.

Outcome: A spreadsheet that reproduces the dashboard's MTBF (2000 hours) and MTTR (5 hours) from raw rows, and a one-line explanation of why a longer repair changes MTTR and not MTBF.

References

1. SMRP: Society for Maintenance and Reliability Professionals, maintenance and reliability metrics. https://smrp.org/
2. Limble: Fiix alternatives and core CMMS features. https://limblecmms.com/?p=26572
3. GetApp: MaintainX against Limble (modules). https://www.getapp.ca/compare/117239/2049215/getmaintainx/vs/limble-cmms
4. EZO: EZO against Fiix and Limble. https://ezo.io/ezo-cmms/blog/ezo-vs-fiix-vs-limble/
5. ISO 55001:2014 Asset management: management systems, requirements. https://www.iso.org/standard/55089.html

Choose one answer for each question, then submit. You will see the right answer and why for every question.

1. What does cmms_asset_profile hold?

AA second asset list kept by the maintenance team, with its own codesBA copy of each work order's labour and parts cost, for the dashboardCMaintenance attributes of a machine, one row on each core_equipment rowDThe failure codes that each equipment class is allowed to use

2. Which module issues permits and owns the lockout procedure, which the CMMS only references?

AM11BM12CM06DM04

3. A job plan has loto_required true. What must exist before its work order can move to in_progress?

AA signature from the planner who scheduled the work orderBA completed task list from the previous work order on the assetCA parts reservation against the storage location of the assetDA permit or LOTO reference, which must be active where the permit module exists

4. How is PM compliance defined in this module?

APM work orders completed within their window ÷ all work orders completedBPM work orders completed within their window ÷ PM work orders dueCPM hours worked as scheduled ÷ all scheduled maintenance hoursDPM work orders generated ÷ the number of assets with a schedule

5. On the seed, an asset runs 8000 hours in a year with four failures. What is its MTBF?

A4 hoursB2000 hoursC8000 hoursD32000 hours

6. What does the partial unique index on cmms_work_order (pm_schedule_id) do?

AIt makes every work order number unique across all tenantsBIt stops a PM schedule from being switched off while orders existCIt lets the engine run only once a day, whatever the schedule saysDIt refuses a second open work order for the same PM schedule

7. A meter PM every 500 units, due at reading 500, is completed at reading 512. If the schedule is fixed, when is it next due?

AAt reading 1000BAt reading 1012CAt reading 1024DAt reading 512

8. What must a corrective work order carry before it can be closed?

AA free-text note of at least one sentence, and the technician's signatureBA failure mode, written by the supervisor, and the total labour costCFour failure keys: mode, cause, mechanism and remedy, each from the right code listDA failure cause only, because the other three can be worked out from it

9. Why can a work order sent twice from a phone not be stored twice?

AThe phone deletes the queue entry as soon as it sends the first timeBThe planner must approve each work order that arrives from a phoneCThe server stores both copies and a person merges them each morningDThe phone made the id itself and the insert does nothing when that id exists

10. A calibration finds an instrument out of tolerance. What must the module do?

AClose the work order and recalibrate at the next scheduled dateBOpen an impact assessment, because earlier measurements may be affectedCRemove the instrument from the asset register so it cannot be usedDChange the tolerance on the job plan so the reading would have passed

11. What does ISO 14224 provide to this module?

AThe rules for issuing a permit to work on isolated energyBThe definition of the PM compliance and MTBF measuresCThe equipment taxonomy and the failure mode, cause and mechanism codingDThe format for sending work orders from a phone to the server

12. How is backlog in crew-weeks calculated?

AEstimated hours of ready backlog ÷ weekly craft capacityBNumber of open work orders ÷ number of technicians employedCHours worked last week ÷ hours of backlog still to be workedDPlanned maintenance hours ÷ total maintenance hours in the month

Submit answers