The short answer
Map the control architecture before writing the outage plan. For each climate zone, irrigation group, energy screen, lighting circuit, water-treatment stage and alarm, identify whether the controller continues locally, which functions depend on the site network, which depend on internet or cloud services, and which require a remote license or vendor connection. Define a safe local operating mode with approved setpoints, prohibited manual actions, inspection intervals, staffing and maximum review period. Keep offline contact, configuration and crop-priority records. Provide an alternate way to communicate alarms and shift status. During recovery, verify network health and authorization before reconnecting, compare controller time and settings, retrieve buffered data where possible, test remote alarms and close every temporary manual override.
Network loss is not one condition. A failed office switch, severed fiber, internet outage, cloud-service failure, wireless interference or deliberate security isolation can remove different functions. Local climate control may continue while mobile alarms and dashboards disappear. Another design may depend more heavily on central servers. The plan must match the installed architecture and software licenses rather than assuming that automatic control always survives.
Manual operation increases workload and error risk. Operators may need to visit panels, compare local sensors, record irrigation events and call the next shift. Reduce the supported production footprint if the available people cannot perform those checks. Manual action should never bypass electrical, motor, weather, pressure, dosing or life-safety interlocks. Where the integrity of the network is in doubt, the controls and IT/OT security owner decides the isolation and restoration path.
This guide is an operating-control framework. The approved design, crop plan, product labels, manufacturer instructions, site safety procedures, local law and directions from competent local professionals govern the actual work.
What the buyer should control
| Control point | Required record or action | Release evidence |
|---|---|---|
| Architecture boundary | List local controllers, servers, switches, gateways, cloud services, remote users, licenses, time sources and communication carriers. | Current diagram and dependency table verified in the field. |
| Function survival | For every crop and utility function, state what continues automatically, what becomes local-only, what loses history and what stops. | Controlled outage-mode matrix based on a functional test. |
| Manual operating limits | Define allowed local commands, approved setpoints, checks, staffing, duration, prohibited overrides and stop conditions. | Time-limited manual-operation sheet at each relevant panel. |
| Offline information | Keep crop priorities, maps, contacts, settings, recipes, recent trends, configuration backups and blank logs available securely offline. | Revision-controlled offline and printed copies with access test. |
| Alternative communications | Provide local alarms, phone, radio, in-person rounds or another approved route for status and escalation. | Coverage and acknowledgement test during simulated network loss. |
| Security and access | Name who may isolate, diagnose, use vendor access, change settings, reconnect and handle suspected compromise. | Authorized IT/OT response path and access record. |
| Recovery and reconciliation | Verify network condition, restore in stages, check clocks, settings, buffered data, alarms, remote views and temporary actions. | Signed recovery test and reconciled event log. |
Every open item needs an owner, due date, status and effect on safety, production, cost and recovery time. A note that something was discussed or is being handled does not prove closure.
A practical workflow
1. Draw the actual control path
Trace sensor data, commands, alarms and history through controllers, local panels, servers, switches, gateways, internet services and phones. Mark local autonomy and hidden dependencies such as name resolution, time, licensing and vendor authentication.
2. Rank essential functions
The grower and operations team define which zones and services need support by season and crop stage. IT and controls staff explain what remains available without each network layer. Resolve conflicting assumptions before writing manual procedures.
3. Write narrow manual instructions
For each supported function, state what the operator may observe and command, where, how often and within which approved limit. Include a handover log and immediate stop conditions. If the workload is too high, reduce the supported crop area.
4. Prepare offline records and communications
Store protected configuration and crop records where authorized people can reach them without the affected network. Test printed contacts, phones, radios or rounds. Control sensitive credentials separately and never place live passwords in a general procedure.
5. Run a controlled isolation test
Controls and IT/OT specialists define the safe test boundary. Observe local automatic functions, alarms, history, clocks, manual steps and remote loss. Do not unplug live equipment casually or disable safeguards to create realism.
6. Operate with explicit review points
During an actual outage, open an event log, confirm the cause is not a wider safety incident, state the supported zones, assign checks and review whether staffing, crop condition or weather still fits the approved mode.
7. Recover without losing the story
Reconnect only through the authorized path. Verify settings and time before accepting data, test alarms end to end, retrieve buffered records, reconcile manual irrigation or climate actions and remove temporary access or overrides.
Preserve the event sequence and earlier versions of records. The team should be able to reconstruct what was observed, which condition applied, who decided, what changed, how the result was tested and which limitation remained.
Who owns each decision
Controls owner
Defines local autonomy, manual limits, configuration state, safe test method and technical recovery of greenhouse controllers.
IT or OT security owner
Controls network diagnosis, isolation, credentials, remote access, evidence and authorized reconnection.
Head grower
Ranks crop zones, adjusts production within approved controls and decides when reduced visibility makes the current crop scope unacceptable.
Duty operator
Uses only approved local actions, performs rounds, keeps the event and handover log, and escalates any condition outside the manual envelope.
Release evidence before the next step
Return to normal networked operation only after the authorized IT/OT owner accepts the network condition, the controls owner verifies controller settings and time, remote alarms and views pass an end-to-end test, missing data and manual actions are reconciled, and temporary access or overrides are removed. Connectivity alone does not prove trusted recovery.
Common failure modes
| Failure | Buyer response |
|---|---|
| The plan says controllers work offline | Test each function and record the loss of history, time, alarms, licenses, recipes and remote support. |
| Manual mode has no workload calculation | Match inspection and logging duties to available trained people or reduce the supported production area. |
| A printed procedure contains live passwords | Use controlled credential storage and grant only the access needed for recovery. |
| The network is reconnected to clear alarms | Let the authorized IT/OT and controls owners assess integrity and restore in stages. |
| Manual commands remain after recovery | Reconcile and remove overrides, local setpoint changes and temporary schedules before closure. |
| Alarm testing stops at the local panel | Continue through network, remote notification, acknowledgement and duty response after restoration. |
Buyer decision questions
Which greenhouse functions are truly local? What disappears with the site network, internet, cloud or mobile service? Can the operator see actuator position and sensor condition locally? How many rounds and manual records can one shift sustain? Which credentials and licenses are needed offline? Who decides the network is trusted again? How will missed irrigation and climate actions be reconciled?
Keep these decisions connected to the controls change management, the emergency call tree test, the climate data troubleshooting. The emergency plan, equipment evidence and crop plan should describe the same operating reality.
Frequently asked questions
Does local automatic control remove the need for a plan?
No. The site may still lose remote alarms, history, coordination, recipes and support. Confirm each dependency and the workload created by reduced visibility.
Should operators switch everything to manual?
No. Preserve approved local automatic control where it remains reliable. Manual action should be limited to documented needs and must not bypass safeguards.
Can a mobile hotspot solve the outage?
Only if the architecture, security and data needs support it and the authorized owner approves it. A hotspot can add exposure or fail during the same regional event.
How often should the outage mode be tested?
Use a risk-based schedule and retest after network, controller, software, license, crop or staffing changes. Test high-consequence paths before relying on them.
What if compromise is suspected?
Follow the site's cyber and incident-response plan. Preserve evidence, isolate only through authorized procedures and do not reconnect merely to regain remote convenience.
Turn the requirement into a controlled deliverable
Provide the control architecture, local and remote functions, alarm routes, crop priorities and current backup procedure. Chengfei Greenhouse can clarify supplied controls while the owner and qualified IT/OT specialists approve isolation, manual operation and recovery.
Contact Chengfei Greenhouse