An operator changes a setpoint in Perspective, the process responds, but the display alone cannot answer who made the change or when it occurred. The Ignition 8.3 audit system can record that user action. Auditing is part of the core Ignition Platform, so the listed license does not require another module or license purchase. It still requires two deliberate commissioning steps: create an audit profile and enable that profile in the project.
What is the screen telling you?
Start with the action visible to the operator. A displayed value may come from a tag, while an editable field, button, or control writes a new value back through its binding. Auditing records supported user actions, including tag writes from Vision or Perspective, after project auditing is enabled.
| Operator observation | Check | Meaning |
|---|---|---|
| The value changes after an edit | Read the bound tag independently of the component | The write probably reached the tag path. |
| The component changes but the tag does not | Inspect the component binding and write configuration | The tag is right; the binding is wrong, or the component is only changing local state. |
| The tag changes without an operator action | Trace the source through the driver and controller | A controller, script, transaction, or another client may be writing it. |
| The process changes but the display does not | Check tag quality, subscription, and binding direction | The screen may be stale or connected to the wrong tag. |
Before configuring the log, perform one test write and confirm that the intended tag changes with good quality. That proves the screen-to-tag path before auditing is added.
Which changes belong in the audit log?
An audit log answers action questions: which authenticated user performed an auditable operation, when it occurred, and what operation was requested. A historian answers value questions: how a process value changed over time. These records complement each other but are not interchangeable.
| Requirement | Use | Reason |
|---|---|---|
| Identify an operator tag write from Vision or Perspective | Audit profile | The record is tied to a supported user action. |
| Trend a parameter continuously | Historian | History follows value samples rather than only user actions. |
| Detect a controller-side value change | Historian or controller diagnostics | A change originating outside the project may have no Ignition user action to audit. |
| Correlate an operator command with process response | Audit profile plus historian | One record identifies the action; the other shows the resulting value trajectory. |
Decide whether the commissioning test is an operator-action test, a value-history test, or both. For parameter accountability, use both configurations when available: the audit record establishes attribution, while history shows whether the commanded value persisted or was overwritten.
How do you create the audit profile?
The platform feature does nothing until an audit profile exists. Configure the profile at the platform level and select its storage type. An SQL-backed profile writes audit entries to a SQL database table, so database connectivity and write access become part of the diagnostic chain.
- Open the platform configuration area used to manage audit profiles.
- Create an audit profile of the required type.
- For SQL storage, select the intended database connection and complete the profile configuration.
- Save the profile.
- Confirm that the profile appears as an available audit destination and reports no configuration or database fault.
| Setting | Location | Effect |
|---|---|---|
| Audit profile | Platform audit configuration | Defines where emitted audit events are stored. |
| Database connection | SQL-backed profile configuration | Routes records to the selected database table. |
| Project profile selection | Project auditing configuration | Connects project actions to the profile. |
At this checkpoint, the profile must be selectable and its storage destination reachable. A profile that exists but cannot write to its destination cannot provide a usable record.
How do you connect the project to the profile?
Creating the profile supplies a destination; it does not automatically activate auditing for every project. Enable auditing in the project and select the created profile. This project-level association is the common missing link when tag writes succeed but no audit entries appear.
- Open the target project in the Designer.
- Open the project auditing configuration.
- Enable auditing for that project.
- Select the audit profile created at the platform level.
- Save and publish the project changes.
- Launch a fresh Vision or Perspective session if the running client does not receive the changed project configuration.
Do not stop after seeing the profile name in the project. Make a controlled write from the actual project runtime and confirm that a new record reaches the selected profile. That proves the project-to-profile connection.
Why can a tag change without an audit entry?
Work backward from the missing record. The audit system observes supported Ignition actions; it is not a universal detector for every physical or logical change in a controller. The origin and path of the write decide what can be attributed.
| Failure point | Diagnostic | Correction |
|---|---|---|
| Project auditing is disabled | Review the active project configuration | Enable auditing and select the intended profile. |
| Wrong profile selected | Compare the project selection with the profile being queried | Point the project and audit viewer or database query at the same destination. |
| UI is not performing a tag write | Observe the bound tag during the action | Correct the binding or write action. |
| Change originates in the controller | Monitor the tag without operating the screen | Use history or controller diagnostics to track that source. |
| Database storage is unavailable | Check connection health and profile errors | Restore connectivity and database write permission. |
| User identity is not distinct | Repeat the test with a known authenticated account | Correct authentication or session identity before relying on attribution. |
Repeat one write after each correction rather than changing several layers at once. The check passes only when the tag changes and one corresponding audit record appears in the configured destination.
How do you verify the complete path?
Use a controlled value that can be changed safely. Record its starting value, the authenticated test account, and the test time. Then trace the same transaction through the screen, tag, driver, controller, and audit storage.
- Open the deployed Vision or Perspective project under a known authenticated account.
- Read the current parameter from the screen and independently from the tag.
- Write a distinct permitted value through the normal operator control.
- Confirm that the tag reports good quality and the commanded value.
- Verify the controller or process endpoint received the intended value where that check is available.
- Query or display the selected audit profile and locate the new tag-write entry.
- Check that the record identifies the expected user, action, target, and time.
- Restore the original parameter through the same operator control.
- Confirm a second audit entry for the restoration and verify the tag and controller returned to the starting value.
This two-write test proves both directions of the operational procedure, distinguishes the change from unrelated traffic, and leaves the parameter at its commissioned value.
Frequently Asked Questions
What happens if I create an audit profile but do not enable it in the project?
The profile exists as a storage destination, but supported actions from that project are not routed to it. Enable project auditing and select the profile before testing a tag write.
What happens if the controller changes the parameter?
The value can change without an attributable Vision or Perspective user action. Use tag history or controller diagnostics to capture the value change and its originating logic.
What happens if the tag changes but the audit table stays empty?
Check the project profile selection, confirm that the write came from the project UI, and verify database connection health and write access. Retest with one controlled write after correcting each layer.
Do I need another license for the Ignition 8.3 Audit Log?
No. Auditing comes with the core Ignition Platform, but it must be configured and enabled. Finish by writing and restoring one parameter, then verify that both actions appear under the expected user in the selected audit profile.