{"id":3713,"date":"2026-10-31T17:00:00","date_gmt":"2026-10-31T09:00:00","guid":{"rendered":"https:\/\/cnbygele.com\/?p=3713"},"modified":"2026-10-30T19:10:48","modified_gmt":"2026-10-30T11:10:48","slug":"meter-readonly-access-test","status":"publish","type":"post","link":"https:\/\/cnbygele.com\/ar\/blog\/meter-readonly-access-test\/","title":{"rendered":"\u0627\u0644\u0648\u0635\u0648\u0644 \u0625\u0644\u0649 \u0639\u062f\u0627\u062f Modbus \u0628\u0648\u0636\u0639 \u0627\u0644\u0642\u0631\u0627\u0621\u0629 \u0641\u0642\u0637: \u0627\u062e\u062a\u0628\u0627\u0631\u0627\u062a \u0627\u0644\u062a\u062d\u0642\u0642 \u0648\u0627\u0644\u0642\u0628\u0648\u0644"},"content":{"rendered":"

Read-only Modbus meter access means the approved monitoring path can retrieve the required measurements while the applicable controls prevent unauthorized changes. Verification should examine the client’s actual requests, the documented device operations, the gateway or network restrictions and the alternative paths that could bypass them. A dashboard without an edit button is not sufficient evidence. Define where the restriction is enforced, test that boundary safely and retain the result with the commissioning records.<\/p>\n

This article provides an acceptance workflow for an authorized monitoring installation. It does not provide write commands, undocumented register addresses or a claim that every power meter supports an internal read-only mode. The BY194 multifunctional power instruments<\/a> are relevant product references, but exact access behavior and communication options require variant-specific documentation.<\/p>\n

Distinguish client behavior from an enforced restriction<\/h2>\n

A monitoring application can be configured to send only read requests. That is useful and should be verified, but it does not necessarily prevent another client from sending a different operation. An enforced restriction exists only where a documented control examines and permits or rejects the relevant access. Depending on the architecture, that boundary could be a supported gateway policy, a suitably capable network control or a device feature confirmed for the exact variant.<\/p>\n

Traditional Modbus function codes include different read and write operations. The Modbus Application Protocol specification<\/a> describes those operations; it does not make a generic dashboard read-only by itself. Function-code filtering also needs to account for documented vendor-specific behavior and any operation that combines reading and writing. Do not assume a rule is adequate merely because its screen uses a reassuring name.<\/p>\n

The NIST operational technology security guide<\/a> provides the broader basis for least privilege, segmentation and controlled access. Apply those principles to the actual network and operational requirements. A restricted monitoring path is one part of the design, and its evidence should state exactly what it covers.<\/p>\n

\"BY194
Product-reference illustration of the disconnected BY194 front beside access acceptance records. Device-specific features and installed options require exact variant documentation.<\/figcaption><\/figure>\n<\/p>\n

Define the approved monitoring path<\/h2>\n

List the source application, its host, the intended gateway or serial interface, the target devices and the allowed measurements. Record who needs routine access and who owns maintenance access. Keep monitoring and maintenance responsibilities distinct enough that temporary commissioning privileges do not become permanent background permissions.<\/p>\n

Identify all plausible paths to the meter. A restricted network gateway may coexist with a local engineering connection or another supervisory system. A test through one path cannot establish the behavior of another. Document any approved maintenance exception, the person responsible for enabling it and how it is closed when work finishes.<\/p>\n

For shared serial networks, consider every connected device and client. A permission rule intended for one meter should not accidentally disrupt another necessary transaction. Review the topology and site constraints before changing gateway or network policies. The Modbus communication setup guide<\/a> provides the practical communication context; this acceptance process adds a specific access-control question.<\/p>\n

Build a bounded acceptance matrix<\/h2>\n

Prepare the matrix before running tests. Use the exact documented functions and points required by the project. The table below describes evidence categories rather than executable commands or a universal device policy.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n
Acceptance item<\/th>\nEvidence to collect<\/th>\nPassing interpretation<\/th>\n<\/tr>\n<\/thead>\n
Required measurements remain readable<\/td>\nApproved request and response samples<\/td>\nMonitoring works within the agreed scope<\/td>\n<\/tr>\n
Routine client sends approved operations<\/td>\nClient configuration and transaction observation<\/td>\nNo unexpected operation appears in the sampled workflow<\/td>\n<\/tr>\n
Restriction is enforced at the stated boundary<\/td>\nSupported policy and controlled test result<\/td>\nThe documented control handles disallowed access as designed<\/td>\n<\/tr>\n
Bypass paths are addressed<\/td>\nReviewed topology and access inventory<\/td>\nAlternative routes are controlled or explicitly qualified<\/td>\n<\/tr>\n
Maintenance exception is temporary<\/td>\nAuthorization and closure record<\/td>\nRoutine operation returns to the approved restriction<\/td>\n<\/tr>\n
Policy survives planned maintenance<\/td>\nConfiguration record and post-maintenance check<\/td>\nThe accepted behavior remains in effect<\/td>\n<\/tr>\n
Monitoring failure is visible<\/td>\nDashboard or collector failure indication<\/td>\nLoss of access does not silently appear as a real zero<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

A passing item should identify the specific evidence and test time. A statement such as security checked is too broad to help the next maintainer. If an item cannot be tested safely, state the limitation and retain the supporting configuration review without claiming a live behavioral result.<\/p>\n

Review the meter and gateway documentation<\/h2>\n

Confirm which interface is actually installed and which functions the application needs. Obtain the applicable register map, supported operation list and any access-related instructions for the exact firmware or option set. Do not infer permissions from front-panel appearance or from another model’s manual.<\/p>\n

If a gateway provides a documented read-only policy, determine its scope. Ask whether it filters by client, device address, function, register range or another rule. Check how it handles unsupported operations, combined operations and maintenance traffic. Determine whether management access can change the policy and how that access is controlled. These are documentation questions, not an assumption that every gateway provides all those features.<\/p>\n

Record the policy configuration and its owner. Retain a versioned copy or supported export where available. The meter configuration backup guide<\/a> covers the wider backup and replacement workflow. A configuration screenshot may support a review, but it does not replace a documented explanation of what the setting actually enforces.<\/p>\n

Observe normal monitoring transactions first<\/h2>\n

Before attempting any negative test, observe the approved monitoring workflow. Check connection startup, ordinary polling, reconnect behavior and any scheduled tasks that run less frequently. Some applications send configuration-related operations during initial setup or recovery. Record what actually occurs rather than assuming that the steady-state polling view represents every operating mode.<\/p>\n

Compare the observed operations with the approved list. Investigate unexpected requests before tightening a policy that might disrupt required monitoring. If the application can disable unnecessary configuration behavior, make that change through the supported procedure and verify it again. Keep the scope narrow so the result remains understandable and reversible.<\/p>\n

Observation has limits. A short capture cannot prove that a rarely used path never sends a different operation. Supplement it with configuration review, application documentation and a test covering the relevant lifecycle events. Record which events were exercised and which remain untested so the acceptance statement reflects the actual coverage.<\/p>\n

Test enforcement without changing production settings<\/h2>\n

Prefer a simulator, spare device or isolated test arrangement that represents the documented control. A negative test should show how the control treats disallowed access without altering a production instrument. Never send an arbitrary write to an operating meter to see what happens. An unverified control could permit it, and the affected setting may have operational consequences.<\/p>\n

If a supported test method exists, use it under the site’s change and safety procedures. Record the authorized setup, expected outcome and actual evidence. When a production boundary must be checked, the responsible team should choose a method that cannot cause an unintended state change. If no safe behavioral test is available, report a configuration-based assessment with that limitation.<\/p>\n

Distinguish where rejection occurs. A gateway rejecting an operation and a meter reporting an unsupported function are different results. A timeout alone does not identify the enforcing component. Correlate the client observation with available gateway or network evidence, and avoid claiming a stronger boundary than the evidence demonstrates.<\/p>\n

Check monitoring behavior after restriction<\/h2>\n

Once the approved policy is active, verify the required measurements under normal operating conditions. Confirm the client can reconnect, the expected polling remains functional and disallowed paths have not been replaced by an unnoticed fallback. A successful connection to the gateway is not the same as a new meter acquisition.<\/p>\n

Make failures visible. If a policy blocks a needed read, the system should mark the reading unavailable under the documented design. It should not retain an old number while presenting it as current. The gateway freshness guide<\/a> explains why access failures and old cached values must be distinguished.<\/p>\n

Check the site’s practical workflow as well. Maintenance staff should know whom to contact for authorized changes and where the temporary exception is recorded. If the approved monitoring restriction routinely forces operators to bypass controls to complete ordinary work, revise the workflow through the proper review rather than normalizing an undocumented workaround.<\/p>\n

\"BY194
Product-reference illustration of the disconnected BY194 front beside access acceptance records. Device-specific features and installed options require exact variant documentation.<\/figcaption><\/figure>\n<\/p>\n

Retest after changes that affect the boundary<\/h2>\n

Gateway replacement, firmware changes, restored backups, management-policy edits and application upgrades can affect the accepted behavior. Identify which events require retesting and include that requirement in the handover package. Do not assume a policy survives a reset or replacement unless the supported behavior and follow-up check establish it.<\/p>\n

The handover package should contain the approved topology, point list, operation list, policy configuration, evidence from normal operation, controlled enforcement test and unresolved limitations. Include the maintenance-exception process and the person responsible for reviewing future changes. This makes the result useful beyond the original commissioning visit.<\/p>\n

Read-only access does not establish confidentiality or complete network security. It also does not establish measurement accuracy, correct units or a suitable register map. The power meter network security guide<\/a> covers the wider protective architecture. Keep each acceptance claim tied to the question actually tested.<\/p>\n

Educational background on least privilege<\/h2>\n

In this Google TechTalks lecture, Berkeley professor David Wagner explains object capabilities and least authority: granting a program the powers it needs for its purpose. That principle supports the distinction between a client choosing to read and an enforced restriction on broader operations. The talk is conceptual background, not a Modbus configuration tutorial. Actual meter and gateway controls must follow their applicable documentation.<\/p>\n