ION Guard - Cold Room (NR-36)
This integration lets ACCELERO query the ION Guard platform before granting access to a cold room, checking whether the worker is within the cold-exposure limits defined by NR-36 (occupational health and safety in meat and derivatives slaughtering and processing companies).
The verification is done in real time by querying the ION Guard API: when trying to access an area marked as a cold room, ACCELERO sends the person's code (enrollment) to the API, which responds whether access is allowed based on the accumulated exposure time. If the worker has exceeded the limit, access is automatically denied.
ACCELERO already has a native cold room/dwell time control, based on access control by identifiers (facial and card readers). This page describes the integration with the ION Guard platform — a tracking product using beacons and antennas — which offers a distinct type of control. The two approaches are independent; see Cold Room for the native feature.
This feature is provided as a plugin (ionguard_camarafria) and must be installed and enabled by the IONGRADE technical team. It depends on an instance of the ION Guard platform accessible by the ACCELERO server.
Current plugin version: 0.1.0 — compatible with ACCELERO 2.16.8 or higher.
What the plugin does
| Feature | What happens in ACCELERO |
|---|---|
| Access verification | Before granting passage to an enabled cold room area, ACCELERO queries the ION Guard API with the person's code |
| Blocking by exposure | If the API indicates that the worker has exceeded the continuous cold-exposure limit, access is denied |
| Fallback policy | When the API is unavailable, access is granted (Fail Open) or denied (Fail Closed) according to the configured policy — global or per area |
| Event recording | Accesses denied by the rule generate the event type 312 — Access denied - ION Guard NR-36 |
| Audit log | Every query (with a response or in fallback) is recorded in the plugin's log table for auditing |
Ensures compliance with the NR-36 cold-exposure limits directly in physical access control, without relying on manual time checks at the workstation.
Configuration
API configuration
Navigation path: Advanced > System > Plugins - ION Guard Cold Room
The Plugins - ION Guard Cold Room screen showing the API base URL, Authentication token, Timeout, and Default fallback policy fields, with the Back and Save buttons.
| Field | Description |
|---|---|
| ionguard API base URL | Address of the ION Guard API (e.g., https://ionguard.exemplo.com.br) — provided by IONGRADE during deployment |
| Authentication token | Bearer token used to authenticate against the ION Guard API |
| Timeout (seconds) | Maximum wait time for the API response. Accepts values from 1 to 10 seconds (default: 3) |
| Default fallback policy | Global behavior when the API does not respond: Deny access (Fail Closed) or Allow access (Fail Open) |
The screen requires administrator permission and is accessed from the settings menu (item Plugins - ION Guard Cold Room).
The base URL and the token are provided by IONGRADE. Both are required — without them, all queries fail and the behavior then depends on the fallback policy.
Per-area configuration
Navigation path: Areas > Edit > ION Guard - Cold Room section
Control is applied per area. In the edit form of each area, the plugin adds the ION Guard - Cold Room section:
The ION Guard - Cold Room section in the area registry, showing the Enable ionguard control switch and the Fallback policy selector with the options Use global default / Allow access (Fail Open) / Deny access (Fail Closed).
| Field | Description |
|---|---|
| Enable ionguard control | Turns the ION Guard verification on or off for this area. When off, the rule is transparent and does not interfere with access |
| Fallback policy | Overrides the global policy for this area only. Keep it at Use global default to inherit the general configuration, or choose Allow access (Fail Open) / Deny access (Fail Closed) |
Access control rule
The plugin registers a dedicated verification rule in the ACCELERO access control engine — ION Guard - Cold Room (NR-36).
Navigation path: in the area configuration, add the verification rule ION Guard - Cold Room (NR-36) to the access flow.
The verification only occurs if the ION Guard - Cold Room (NR-36) rule is present in the access control flow of the desired areas. Simply enabling the control in the area section is not enough — the rule must be assigned.
Access control flow of an area with the ION Guard - Cold Room (NR-36) verification rule assigned.
How the rule decides
For each access attempt to a channel whose destination area has the control enabled:
- Area not enabled — if the destination area does not have ION Guard control enabled, the rule is transparent and access is authorized by it.
- Person without a code — if the person does not have a registered code (enrollment), the rule applies the area's fallback policy.
- Query to the API — the rule sends the person's code to the ION Guard API and waits for the response within the configured timeout.
- API unavailable — if the API does not respond (timeout, network error, invalid response), the rule applies the fallback policy.
- Access denied by the API — if the API responds that access is not allowed, the rule denies access and records the event type 312.
- Access allowed by the API — if the API responds that access is allowed, the rule authorizes access.
The calculation of the cold-exposure time and of the maximum continuous limit is done by the ION Guard API, not by ACCELERO. ACCELERO only queries the result and applies the decision in access control. The API response includes the accumulated exposure time and the worker's maximum continuous limit.
Fallback policy
The fallback policy defines the behavior when the ION Guard API cannot respond.
| Policy | Behavior |
|---|---|
| Deny access (Fail Closed) | Denies access. Prioritizes worker safety. It is the default |
| Allow access (Fail Open) | Allows access. Prioritizes operational continuity |
The policy can be defined globally (in the plugin configuration) and overridden per area (the Fallback policy field of the ION Guard section in the area edit form). When the area is set to Use global default, the global policy applies.
Fail Closed may block workers during an API outage; Fail Open may grant accesses without the NR-36 exposure check. Set the policy according to the criticality of the operation and the customer's risk tolerance.
Recording and auditing
All the plugin's queries are recorded for auditing, regardless of the result.
| Situation | What is recorded |
|---|---|
| Query answered | Full API response: whether access was allowed, denial reasons, accumulated exposure time, maximum continuous limit, HTTP status, and response time |
| Fallback applied | Person, area, applied fallback policy, and the flag that the result came from a fallback |
The record includes the person's code (enrollment), the destination area, and the query date/time. Accesses denied by the rule also appear as event 312 — Access denied - ION Guard NR-36 in Logs and Monitoring.
The access events denied by the rule are available in the ACCELERO access logs. The detailed log of the ION Guard API queries is written to the plugin's own table, aimed at technical auditing.
Use cases
Enable control in a cold room
- Request that IONGRADE install the
ionguard_camarafriaplugin and access to the ION Guard API. - In
Advanced > System > Plugins - ION Guard Cold Room, fill in Base URL, Token, Timeout, and the Default fallback policy. - In the edit form of the area that represents the cold room, enable Enable ionguard control in the ION Guard - Cold Room section.
- Add the verification rule ION Guard - Cold Room (NR-36) to that area's access control flow.
- Make sure the regulated people have a registered code (enrollment).
- Test a passage and check the result in the access logs.
Set a different fallback per area
- Set the more conservative global policy (e.g., Fail Closed) in the plugin configuration.
- In a specific area that cannot block during outages, open the ION Guard - Cold Room section and choose Allow access (Fail Open) in the Fallback policy field.
- Keep the other areas at Use global default.
Best practices
- Person code filled in: people without a code (enrollment) are not queried in the API and fall into the fallback policy. Ensure the enrollment in the registry of the regulated workers.
- Adequate timeout: values that are too low increase the chance of a fallback; high values may delay the release at the barrier. The default of
3seconds is a good starting point. - Rule assigned to the right areas: confirm that the ION Guard - Cold Room (NR-36) rule is in the flow of each cold room area — enabling the control in the area is not enough.
- Fallback aligned with the customer: decide Fail Open vs Fail Closed together with the customer's OHS officer, balancing safety and operational continuity.
Troubleshooting
Access is not being verified
Possible causes:
- ION Guard control not enabled in the area
- The ION Guard - Cold Room (NR-36) rule not assigned to the area's access flow
- Plugin not installed/enabled
Solution:
- In the area edit form, confirm that Enable ionguard control is on.
- Confirm that the ION Guard - Cold Room (NR-36) rule is in the area's access control flow.
- Check with IONGRADE support whether the plugin is enabled.
Accesses are all being denied (or all granted) unexpectedly
Possible causes:
- ION Guard API unavailable and fallback triggered (Fail Closed denies everything; Fail Open grants everything)
- Incorrect base URL or token
- Timeout too low
Solution:
- Check the base URL and the Authentication token in the plugin configuration.
- Test the connectivity of the ACCELERO server to the ION Guard API (HTTPS).
- Adjust the Timeout if the network is slow.
- Review the Fallback policy globally and per area.
A specific worker always falls into the fallback
Possible causes:
- Person without a registered code (enrollment)
- Worker not found in the ION Guard API
Solution:
- Confirm the code in the person's record.
- Check with the team responsible for the ION Guard API whether the worker is registered there.
Integration with other modules
Areas
Control is configured and enabled per area. The ION Guard - Cold Room section is added to the area edit form by the plugin.
Controllers
The verification occurs on passage through a controller channel whose destination area has the control enabled.
Logs and Monitoring
Accesses denied by the rule generate the event 312 — Access denied - ION Guard NR-36, visible in Logs and Monitoring.
Next Steps
- Cold Room — Native ACCELERO cold room control (via access control)
- Areas — Enable ION Guard control in the cold room areas
- Controllers — Understand the passage flow that triggers the verification
- Logs and Monitoring — Check the denied access events
- Plugins — Learn more about the ACCELERO plugin system