Skip to main content

Simulator

The access simulator is an administrative tool that lets you simulate actions that usually depend on physical interaction with controllers.

Navigation path: Advanced > Simulator

Administrative Tool

This tool is intended for quick testing and should be used only by properly trained operators.

How It Works

The simulations are handled by ACCELERO as if the events were happening on real controllers.

Characteristics

  • Logs generated normally: All simulations generate event logs
  • Full validation: The system applies all access rules
  • Real time: Simulations happen instantly
  • Auditable: Everything is recorded in the operation log
Production Environment

Be careful when using the simulator in a production environment, as simulated events are indistinguishable from real events in the logs.

Actions That Can Be Simulated

1. Access Requests

Simulates that an identifier was presented at a given controller/channel.

Configuration:

FieldDescription
Identifier numberInternal number of the identifier to simulate
ControllerController where the access is being simulated
ChannelSpecific channel of the controller
Access typeUnidirectional or Bidirectional

Typical use:

  • Test access permissions
  • Validate category × area × time range settings
  • Check anti-passback operation
  • Test offline contingency

Example:

Identifier: 12345
Controller: MAIN GATE
Channel: Channel 1 (Entry)
Type: Unidirectional

Result: The system validates permissions and generates an event log
Configuration Testing

Use simulated access requests to test settings before putting them into production.

2. Controller Log

Simulates the sending of a log by a controller.

What can be simulated:

Event TypeRequires Identifier
Passage confirmation✓ Yes
Access denied✓ Yes
Open door alarm✗ No
Opening by button✗ No
Sensor violation✗ No
System events✗ No

Typical use:

  • Test log processing
  • Simulate alarm situations
  • Validate the behavior of special events
  • Train operators

Example 1 - Passage Confirmation:

Event type: Passage confirmation
Identifier: 67890
Controller: GARAGE ACCESS
Channel: Channel 2 (Exit)

Result: The system records that the person passed through the blocking point

Example 2 - Alarm:

Event type: Open door alarm
Controller: SERVER ROOM
(Does not require identifier)

Result: The system generates an alarm incident

3. Escort Simulation

Simulates the access confirmation by an escort.

When to use:

  • Test the escort feature
  • Validate the configuration of categories that require an escort
  • Train operators on the escort flow

Difference from a normal request:

  • Used specifically to simulate access authorization after an escort request
  • Represents the "second step" of the dual verification process

Example:

Step 1: Person with a category that requires an escort requests access
→ The system waits for escort confirmation

Step 2: Use "Escort simulation" to confirm
Escort identifier: 55555
Controller: RESTRICTED AREA
Channel: Channel 1

Result: Access is granted after escort validation

See Categories - Escorts for configuration.

Simulator Interface

Simulator screen

Common Fields

Most simulations require:

  1. Select the simulation type (dropdown)
  2. Enter specific data (identifier, controller, etc.)
  3. Click "Simulate"
  4. Check the result (an event log is generated)

Visual Feedback

After running a simulation:

  • Success: Message confirming that the simulation was executed
  • ℹ️ Information: Details of the generated event
  • 🔗 Link to the log: Direct access to the created event log

Practical Use Cases

Case 1: Testing a New Configuration

Situation: You created a new category "TEMPORARY" with access to "ROOM 10" only during "BUSINESS HOURS"

How to test:

  1. Create a test identifier: 99999
  2. Associate the identifier with a test person
  3. Associate the test person with the "TEMPORARY" category
  4. Use the simulator:
    • Identifier: 99999
    • Controller: That controls ROOM 10
    • Current time: Within business hours
  5. Check: Access should be authorized
  6. Change the system time or use another time
  7. Check: Access should be denied outside business hours

Case 2: Operator Training

Situation: Train new operators on the event flow

How to use:

  1. Simulate various event types
  2. Ask operators to observe the logs
  3. Teach how to interpret each type
  4. Simulate problem situations (denials, alarms)
  5. Train incident resolution

Case 3: Troubleshooting

Situation: A user complains that they cannot access an area

How to diagnose:

  1. Note the user's identifier number
  2. Use the simulator with that identifier
  3. Observe the simulation result
  4. The log will show exactly which validation failed
  5. Fix the configuration according to the diagnosis

See FAQ - Why was access denied? for more details.

Limitations

What CANNOT be simulated

The simulator does not simulate:

  • Physical commands to open blocking points
  • Real communication with controllers
  • Real offline/contingency situations
  • Faulty hardware
  • Network problems

Best Practices

  1. Use in staging: Whenever possible, test in a separate environment

  2. Document tests: Keep a record of the tests performed

  3. Clean up test logs: Delete simulation logs after testing in production

  4. Identify tests: Use specific identifiers for tests (e.g., 99900-99999)

  5. Train before using: Make sure the operator understands what they are doing

  6. Check results: Always confirm that the simulation had the expected effect

  7. Do not overuse: Do not use the simulator excessively in production

  8. Combine with other logs: Use it together with the event and operation logs

Security

Access Control

Access to the simulator must be restricted to technical operators. Configure appropriate permissions in the profiles.

See Profiles for permission configuration.

Next Steps