Split industrial computing by function before choosing a platform. Collecting equipment readings, showing local status, comparing sites, and preserving history have different requirements. Some belong near the equipment. Others benefit from a shared remote service. One project can sensibly use both.
At a remote grain-drying and handling site, the supervisor needs a usable local view. Planners elsewhere need historical comparisons. Neither need implies that a general-purpose monitoring computer should control the dryer. The useful question is where each responsibility can be delivered and supported.
Separate the work before placing it
Edge means computing on equipment or nearby site hardware. Cloud means remote computing services. Those labels identify locations, not complete operating designs. A site computer and an equipment controller can both be local while having very different permissions and capabilities.
- Acquire
- Collect readings from approved sources.
- Buffer
- Hold records temporarily before their next destination.
- Show status
- Present readings with their age and quality.
- Analyze
- Compare records to answer an operating question.
- Archive and report
- Preserve history and serve shared views.
- Control
- Remain within the qualified equipment-control design.
NIST's 2018 Fog Computing Conceptual Model describes intermediate computing nodes between devices and centralized services. It provides background for thinking in layers.
Give each function an input, an output, a user, and an owner. A local collector might produce timestamped observations. A remote report might combine those observations with delivery records. Describing the outputs makes it easier to place the work without buying an entire platform by default.
Set timing requirements for each use
A fast network connection is not a timing requirement. Ask how old information may be when used, when a result must be ready, and what happens if that requirement is missed. Separate an operator's routine status view from a planning report.
| Use | Requested timing |
|---|---|
| Routine site status | Readings no more than 10 seconds old. |
| Previous-day planning report | Available by 08:00 site-local time the next day. |
| Historical comparison | Updated for the weekly planning review. |
For the status view, account for acquisition, collection, processing, and display delay together. A nearby server can still show old data. A remote service may meet a planning deadline even when it cannot meet a more demanding status requirement.
Record the site time zone in the brief. The planning report must state its data cutoff and coverage; arriving on time with incomplete records does not satisfy the reporting need.
Equipment response requirements belong to the qualified control design. They are not established by the status-page target above. Keep monitoring and control distinct, and have the responsible engineers assess any proposed change to that boundary.
Allocate the grain site's functions
Hypothetical worked scenario
Site GH-03 is invented. It has grain storage, a drying system, and handling equipment with existing qualified controls. The proposed monitoring project adds a site computer and a remote history service. It supplies information for review, not drying instructions or equipment commands.
For this invented brief, routine status must not require remote analysis for each refresh. Verify that requirement against actual identity and configuration dependencies. It is a monitoring requirement, not an instruction for equipment operation when connectivity changes.
| Function | Proposed location and reason |
|---|---|
| Acquire observations | Approved equipment-side interfaces; direct source access. |
| Buffer records | Site computer; bounded temporary holding. |
| Show routine status | Site computer; refreshes must not require remote analysis. |
| Analyze local trends | Site computer; narrow comparisons for the supervisor. |
| Archive history | Remote service; managed historical records. |
| Compare sites and report | Remote service; shared records and planning users. |
| Control and protection | Existing qualified systems; outside the monitoring computer. |
The site supervisor reviews status and notes. The central operations analyst prepares comparisons from the historical record. Architecture record GH-03-A holds the allocation, interfaces, owners, and approval conditions. The existing controls documentation remains authoritative for equipment behavior. Record proposed and accepted placements separately. Site and central owners must review the supporting evidence before accepting their responsibilities.
This matrix is a starting proposal. If local trend analysis consumes resources needed for collection, it may move to the remote service. If the status view depends on remote processing, the team must reconsider whether that path meets the site's requirement.
Check data volume and computing headroom
Estimate the records each function must handle before choosing hardware or a service plan. Data volume affects transport, storage, and processing. Headroom means spare capacity for realistic peaks and maintenance work, beyond the ordinary workload.
- Invented input
- 12 channels, one record per second, 32 bytes per record.
- Record rate
- 12 times 1 times 32 equals 384 bytes per second.
- Daily period
- 24 times 60 times 60 equals 86,400 seconds.
- Daily record payload
- 384 times 86,400 equals 33,177,600 bytes. Divide by 1,000,000 for 33.1776 decimal MB, about 33.2 MB.
- Excluded
- Transport overhead, indexes, logs, and other stored copies.
Different data can change this estimate sharply. Images, diagnostic files, and frequent equipment events need their own accounting. Reducing records locally may save transport, but summaries can remove detail needed for later investigation. Decide which original evidence must remain available.
Microsoft's Azure IoT Edge production checklist notes that module resources are not limited by default. A module is a packaged software component. This platform-specific example reinforces the need for explicit resource assessment.
Test collection, status, and analysis together on the proposed hardware. Include logging and approved update work. A processor that handles each job separately may still be unsuitable when the jobs compete for memory, disk access, or processing time.
Trace what crosses the boundary
Drawing the computer inside the site boundary does not establish independence from remote services. Identify the information, identities, and configuration each function needs. Review dependencies for ordinary operation, updates, and recovery separately. A certificate is a digital credential used in authentication.
- Data
- Which observations and summaries leave the site?
- Identity
- Which certificates or accounts permit each connection?
- Configuration
- Where do software versions and approved settings originate?
- Time
- Which clock source supports comparable records?
AWS's Greengrass device-authentication documentation describes certificates and policies used for connections and deployment. It is a platform-specific example of dependencies that remain relevant to local computing.
A local application may have its software already installed but still need a remote registry when rebuilt. A certificate change may affect a particular connection. Assign those dependencies to owners and verify the actual configuration. Neither a local enclosure nor a hosted service alone establishes an adequate security design.
For GH-03, the monitoring path carries observations toward the remote history service. It does not introduce a route for reporting software to issue equipment commands. Changes to equipment authority need their own engineering process.
Name who supports each placement
Putting work at the site creates a local support obligation. Putting it in a remote service creates service-management obligations. A cloud support agreement cannot by itself replace a failed site computer or restore power to it.
| Responsibility | Named role to confirm |
|---|---|
| Site hardware and source access | Site maintenance lead, with qualified engineering support. |
| Collection and status software | Application maintainer with an agreed site contact. |
| Historical service and shared reports | Central service owner and operations analyst. |
| Identity and configuration changes | Security and application owners, with coordinated approval. |
Ask who can attend the site, diagnose the running version, recover the approved configuration, and obtain a replacement. Check suitable power, installation environment, and service access with qualified site personnel. These practical limits may change which local functions are supportable.
Remote services also need defined access, retention, backup, and change ownership. A shared report needs an owner for its definitions and completeness. Make the handoff between local records and central reporting explicit instead of leaving each team to assume the other owns it.
Review the split before expanding it
Approve an allocation against evidence for each function. Timing, continuity, resource capacity, and support should have an acceptance condition and a responsible reviewer. A convincing platform demonstration does not establish that the proposed combination works at this site.
| Changed requirement | Allocation question |
|---|---|
| More urgent status information | Can the full path still meet the required age? |
| Larger analysis workload | Should it leave the collection computer? |
| New cross-site comparison | Which common records should move centrally? |
| Loss of local support | Can the proposed site responsibilities still be maintained? |
Ordinary software can collect records, calculate summaries, and serve status. Optional AI may help review approved notes or support historical analysis, with source records available to the reviewer. It gains no control authority or permission to approve equipment behavior.
For GH-03, the next step is to complete the allocation record with the site supervisor, controls engineer, application maintainer, and central service owner. Demonstrate the chosen responsibilities together before expanding the design. The result should be a supported division of work, not a declaration that edge or cloud wins.