Mission Engineering 08: Modeling Hand-Pour Coffee with OPM — Objects, Processes, and States

Starting with "Heating Water" to Illustrate OPM Basics

The article begins with a simple statement: "Heat the water needed for this brew using a kettle." In OPM, the water is an Object , heating is a Process , and "water temperature below selected range" is a State of that object. The temperature reading and the recipe-defined range are separate: the range and reading must exist before the state can be determined.

Object : Water for this brew — represented by a rectangle.

Process : Heating — represented by an ellipse.

State : Below selected temperature range, within selected temperature range — represented by a rounded rectangle inside the object box.

These are the basic graphical conventions of OPM per ISO 19450:2024. The diagram shows the water changing state from "below range" to "within range" via the heating process. The water remains the same object; it is not consumed and recreated. Actual satisfaction of the condition must be verified when the water is needed, not assumed just because heating occurred.

If the water is already too hot, that requires a separate expression. "Below range" and "above range" are distinct conditions; "temperature not yet measured" is insufficient information, not a temperature fault.

The kettle participates in heating but plays a different role: the water changes state, while the kettle provides the heating condition. This distinction must be clear before drawing connections.

Same Process, Completely Different Roles

Examining manual pouring: you operate, the kettle supports, water enters the coffee bed. Writing all three as "participates in pouring" would connect the diagram but leave the reader unaware of who acts, who provides conditions, and what changes.

OPM separates these roles into Enablers (support the process without being transformed) and Transformees (objects that are transformed, including consumed, generated, or affected). The mapping with coffee-model examples:

Enabler — collective term for operators and instrument resources below.

Agent — person executing the process (you during continuous manual pouring).

Instrument — provides required support (kettle during pouring; phone during recording).

Transformee — collective term for the three sub-roles below.

Consumee — consumed within model boundary (coffee grounds and brewing water invested in the full brew).

Resultee — generated by the process (brewed coffee liquid and spent wet grounds).

Affectee — object persists, state changes (water during heating; current record when data is appended).

Here Agent refers to the human executor, not an LLM assistant. Instrument is not limited to physical tools: the recipe information that the process reads but does not modify is also modeled as a supporting condition.

These relationships can be expressed in OPL (Object-Process Language), a controlled natural language that corresponds one-to-one with the Object-Process Diagram (OPD). The article provides a coffee-example fragment using publicly documented sentence patterns:

Water can be below-range or in-range.
Heating changes Water from below-range to in-range.
Heating requires Kettle.
Operator handles Pouring.
Pouring requires Kettle.

The first three sentences describe the water's two temperature states, the state change caused by heating, and heating's need for the kettle. The last two state that manual pouring is performed by the operator and also requires the kettle. The operator is you (CF-RES01). Per the assumptions in article 06, during electric heating you do not need to continuously operate, so you are not linked to the entire heating process; startup and verification are listed separately.

This bimodal (graphical + textual) representation lets stakeholders check relationships visually and verify meaning sentence by sentence, both referring to the same model. Tools that support bimodal modeling can generate OPL automatically, enabling both domain experts and engineers to use their preferred view. If a condition like "all records must be entered before serving" later appears in the model, it can be read aloud to confirm it matches the actual agreement.

Roles must be judged per specific process. Water changes state in "heating" but is consumed as material in the full "brew"; the phone supports "recording" while the record inside it is modified. An object's role cannot be fixed once and reused everywhere.

"Consume" and "generate" express transformation within the chosen system boundary; they do not imply matter vanishes. How coffee beans, grounds, and liquid are modeled depends on the analysis scope — do not lump all before/after changes into a single object's state list.

Focus on Brewing and Recording First, Not the Whole Morning

The current model starts after preparation checks pass, examining how the coffee liquid is produced and how the agreed data gets recorded. Only the successful path is modeled here; gaps and interruptions are addressed in the next article.

Grinding, heating water, serving, collecting feedback, and post-session 정리 remain in the original task tables and are not forced into this partial diagram.

Treating this work segment as a whole without expanding internal actions yields the "partial top-level" view. The central process is named "Brew and Record Field Data" (CF-OP01). OP denotes a process in the model, distinct from the earlier CF-A task numbering, with its own versioning. The objects related to CF-OP01 and their relationships:

Current coffee grounds, water allocated to this brew — Material input, consume relationship; come from completed preparation; not all water remaining in kettle counts as input.

Current coffee liquid, wet grounds — Process output, generate relationship; main products listed; residual and loss paths not yet detailed.

Current record — State change; created before entry, field data pending; after normal completion, agreed field data entered.

Selected recipe — Information support (enabler); linked to confirmed version; recipe not modified by this process.

You, CF-RES01 — Agent; same person as in article 06.

Kettle, scale, phone, filter and receiving vessels — Instrument resources; reuse existing resources; which sub-process uses which is detailed at the next level.

Reading the table as a sentence: "You use existing equipment, brew according to recipe, grounds and water become coffee liquid and wet grounds; during that time, you also record the data." Two activities combined; specific sequencing and recording timing require further decomposition.

Putting brewing and recording in the same model must not implicitly add a requirement that "all recording must finish before serving." Checkpoint A04 verifies whether coffee is ready to serve and whether you are free to continue. Which data must be recorded on the spot and which can be 정리 later depends on recording requirements and whether information can be retained, and must be checked for impact on serving time.

"Field data entered" means all agreed field-data items for this round are filled; a phone "save success" toast alone does not suffice. Accuracy and source reliability are verified separately; later evaluation and 정리 are not part of this state. Coffee taste and serving time are still checked per earlier agreements.

Before entering this model segment, brewing conditions per CF-REQ03 must be verified. Water meeting its condition satisfies only one item; coffee grounds, filter, and receiving vessels must each be checked and their usable status recorded per CF-E01.

Expanding Reveals Where Recording Fits

Looking only at "Brew and Record Field Data" does not show which segment requires setting down the kettle or when recording can happen. The process is expanded (in-zooming) to show internal processes and related objects, per OPM's in-zooming capability. The sub-processes (row order does not imply strict serial execution nor a finalized schedule):

Complete this manual pour segment (CF-OP01.1) — This segment of water moves from kettle into coffee bed, changing position state; same you operate kettle, read timing and volume info from recipe.

Extraction and filtration (CF-OP01.2) — Within full brew scope, grounds and water form coffee liquid and wet grounds; dripper, filter paper, receiving vessel provide support; physical process not equated to continuous manual operation.

Read field information (CF-OP01.3) — Obtain this segment's readings, associate source and read time; does not yet imply saved; you read scale or phone info, verify if retrievable later.

Enter this segment's data (CF-OP01.4) — Modify corresponding segment fields in current record; same you use same phone, enter and save based on observed info.

CF-OP01.2 consumes dry grounds and brewing water, generates coffee liquid and wet grounds, expressing material transformation for the brew. If component transfer or mass balance of water and grounds is needed, objects must be further subdivided, measurements added, and residues and losses accounted for. Model granularity depends on the question being answered; these input-output relations cannot replace material balance calculations or chemical process simulation.

Pouring is only part of the full brew; "pouring complete" cannot be written as "extraction fully complete." Pouring, extraction/filtration, and reading may overlap. Further decomposition must specify which actions repeat, when each can start, and which are still ongoing — the four rows cannot be simply chained into a single line.

CF-OP01.1 is the model ID for "this manual pour segment." A cup may have multiple pour segments; each execution records brew ID, segment number, actual start/end — they cannot share one actual record. Here pouring only represents water moving from kettle to coffee bed; material transformation during extraction/filtration connects to CF-OP01.2, avoiding double-counting the same water.

After decomposition, cross-check with the upper-level table: the upper level uses the existing "current record"; the lower level continues filling that record. If a new record must be created in practice, that action must be added and the upper level re-verified.

Revisiting article 07's idea: "enter previous segment's data after setting kettle down." This can serve as a provisional recording arrangement but cannot substitute for a reading arrangement. Opening the phone only at the end cannot automatically recover readings that were never captured at the start. CF-OP01.3 must specify when information is obtained and how long it can be retained. "You saw it" does not equal "phone already saved"; if only memory can be used for backfill, that must be noted and not treated as retrievable raw data.

Records and physical actions must be separated. "This segment complete" in the record must correspond to the actual pour segment that occurred; a filled form does not guarantee the physical actions met requirements.

Two Lines Connect to You — What's Missing?

Connecting an "operator" to pouring and another "operator" to recording raises the question: are both boxes the same person? If not clarified, the diagram author thinks there's only you, but the scheduler might assume two people.

The example continues using CF-RES01 to denote you. Even if it appears in multiple expanded diagrams, it is still the same person — no extra helper appears. "Operator" is a role name; "you who are responsible for operation this time" is the concrete object whose occupancy must be verified.

Adopting the capacity assumptions from article 06: continuous manual pouring and manual phone recording each exclusively occupy your operating capacity during their active periods. For these two operation types only, available capacity = 1, each needs 1 — this is not generalized to "a person can never do two things at once."

CF-OP01.1 Manual Pour — Resources: CF-RES01 you, CF-RES02 kettle. Occupancy: from picking up kettle to prepare this pour segment, through end and setting kettle down; you can switch tasks, kettle retained for subsequent water.

CF-OP01.3 Read & CF-OP01.4 Enter + operation prep — Resources: CF-RES01 you, CF-RES05 phone, and actual reading sources. Occupancy: per 06/07 boundaries: from picking up phone, switching pages, through reading and input, to saving this item; if reading moves earlier, list occupancies separately, do not omit.

Keep this table and capacity assumptions beside the model for later scheduling. Picking up the phone and switching pages are already included in the reading and recording occupancy intervals; finer decomposition must still locate these actions. Two operator links alone do not reveal duration, interruptibility, or latest finish time.

If reading is already included in the overall recording time agreed in articles 06/07, do not add it again. If timed separately, each segment's occupancy must trace back to the original plan; watching the scale during pouring for volume control cannot be arbitrarily treated as a new exclusive operation without analysis.

The next article will insert planned time windows to check: if recording is incomplete when the next pour segment should start, can the arrangement still hold? Shared operator on the diagram does not by itself prove conflict, let alone deadlock.

After Drawing, Cross-Check with Original Task Tables

At this point, review earlier tables: what entered the model, what stays in the tables for verification? Flowcharts, BPMN, etc. can also express multiple relationships; parts already clearly expressed can continue using those methods.

The example retains at least the following correspondences:

CF-A02 prep results, CF-REQ03, CF-E01 — Expressed as material & equipment conditions before CF-OP01 entry; still need to verify: drawing conditions does not mean they are satisfied on site.

CF-A03 Complete Brew — Expressed as pouring, extraction & filtration within CF-OP01; still need to verify: obtaining coffee liquid does not mean CF-REQ02 taste agreement is met.

CF-REQ04, Option B extra record items — Expressed as current record, reading & recording processes; still need to verify: extra per-segment items must not be mixed into CF-R01 common basic items comparison.

CF-A05 Organize Records — Expressed as handoff between field records and later 정리/评价; still need to verify: cannot defer all information collection to A05.

CF-REQ01 Serving Requirement — Expressed as coffee liquid usable state, operator occupancy & CF-A04 handoff; still need to verify: do not arbitrarily make full recording completion a prerequisite for serving.

A task may need several processes to explain; the same record may be filled across several tasks. Therefore, moving from Mission Threads (MT) and Mission Engineering Threads (MET) to OPM requires item-by-item verification of "what does this do, what changes" — not just replacing task boxes with ellipses.

During review, have a practitioner read each relationship as a sentence: what must exist before this process starts? what changes after it ends? are the people and equipment still the same? Any sentence without basis goes back to the task, resource, or recording plan for completion.

Try Your Own Business: Start with One Handoff

Practice with a spare-parts pickup: the part is a physical object, pickup is a process, the log is an information object, the storekeeper is the person whose occupancy must be checked. Unlike brewing, the part moves from storage to the requester but usually remains the same item — cannot copy the consume relationship of grounds and water. Scope it to a single handling that yields visible results within a day or two.

Fill the small card below before deciding how to draw:

Question to check in this session:
Scope boundaries — where does the local scope start and end:
Process name & ID, linked to which task:
Which objects are consumed, which generated:
Which object persists but what state changes:
Who operates, using which specific tool resources:
Where do input facts or information come from:
Required conditions, linked to which requirements:
Where are occupancy, capacity, release conditions recorded:
What remains assumptions, how to validate:

After drawing, ask someone to read it back: what did things become, what was recorded, who are the people and equipment on the diagram? Where they cannot answer, go back and fill that spot — no need to add more boxes and lines yet.

Summary

The extra recording items from Option B now have concrete places: information must be read, the record must be modified, and both actions use the same you. The next article will follow this partial model, adding operation time windows and exception scenarios to see whether the arrangement can actually be executed.

References

ISO, ISO 19450:2024, Automation systems and integration — Object-Process Methodology, official abstract. Used to verify standard version and conceptual modeling purpose; this article does not claim conformance to specific diagramming clauses based on the abstract. URL: https://committee.iso.org/standard/84612.html?browse=tc

Dov Dori et al., Object-Process Methodology as an Alternative for Human Factors Task Analysis, author's public draft, Section 2.1. Used to explain basic expression of objects, processes, states, layered OPDs, and corresponding OPL. The coffee relationship tables, numbering, Chinese glosses, and occupancy constraints in this article are instructional designs, not tool-generated OPL or simulation results. URL: https://dovdori.technion.ac.il/wp-content/uploads/2021/09/OPM-as-Alternative-2nd-Rev-2021-07-29.pdf

Dov Dori, Modeling system, US20070050180A1, FIG. 36 related description. Used to cross-check enabler, transformee, and role terminology. This material predates the 2024 standard and is not proof of specific 2024 clauses or current tool behavior. URL: https://patents.google.com/patent/US20070050180A1/en

Dov Dori, Extending the Human Spatiotemporal Comfort Zone with CAVERN – Computer-based Augmented Virtual Environment for Realizing Nature, Journal of Multidisciplinary Research, 4(3), 2012, 23–44, Fig. 3 and related description. Used to verify OPL state enumeration, state change, instrument requirement, and operator sentence patterns, and diagram-text correspondence. This article adapts those sentence patterns for a self-created coffee example and does not claim the fragment has passed tool parsing or full 2024 standard conformance check. URL: https://dovdori.technion.ac.il/wp-content/uploads/2022/02/JMR_Galley_Dori2.pdf