Log who checked the part: operator identity in HMI alarm records

Should the operator's password be written to the log?

No: write the account name to the log and keep the credential out, because a check record needs one identifier that maps to one person, and a password maps to a password box, not to a person.

The request behind the question is traceability, and the password is the wrong field for it. Passwords get shared when the line is busy, they rotate on schedule, and the moment one lands in an alarm message, every export, file transfer and backup of that database carries a working credential. Leave the credential out and the export is safe to send anywhere.

If the part is FDA regulated, the bar is written down. The FDA rule on electronic records and electronic signatures sets the criteria under which those records and signatures are accepted, and a signature under it carries the signer's name, the date and time, and the meaning of the signing, such as performed the check. The password belongs to the authentication step, and it stays there.

Does the alarm history already show who checked the part?

No: an alarm log records the process condition and its timestamp, and the account field stays empty unless the project writes a separate event, so the alarm history answers when, not who.

Alarm logging exists to document error states in the monitored process: which condition fired, when it fired, when it cleared. A log-on is a different class of event, a security event about a session. The two land in the same database only when the project puts them there. An alarm at 14:32 and a clear four minutes later give you the window of the check. The name of the person inside that window comes from one place: a record written while that account was authenticated.

One limit is worth knowing before you design anything. The history holds only what was captured while logging was on, which is why an alarm history downloads only if logging was on before the events you care about.

Which three events make up the check record?

Three: the alarm trigger, the operator log-on, and the check-completed event, each with a timestamp to the second, and the third one carries the authenticated account that cleared the alarm.

Audit trails in alarm systems record the user and the action taken on the alarm, and the usual actions are acknowledge, close, assign and clear. Your check is the clear, and its record has to carry the account, the time to the second, and words that say what happened, such as part check completed.

If you also need a record of every interaction, logging the operator, button and time for every HMI press is the wider net. For this request the three events above are enough, and they read faster in an audit.

How do you set up the three events on the panel?

In six steps: switch on alarm and event logging at the finest storage interval, add a log-on event that writes the account, and generate the check-completed record on the alarm clear with the active account in the message text.

You need the project open with edit rights in the HMI design software, a logging destination the panel can reach, one account per operator in the panel's user list, and one alarm you can force for the test.

1. In the design software, switch on alarm database logging for alarms and events, set the storage interval to its finest setting so the three records keep their order, and confirm the destination holds records for your quality system's retention window. Your HMI software's own documentation names the exact setting for alarm database logging.
2. Leave the alarm trigger alone: the alarm bit already writes its message and timestamp.
3. Add the log-on event. Design tools expose log-on and log-off event commands in the Security category of the event list; the older pattern is a bit set at log-on that writes a message carrying the account name. Both produce the same row.
4. Build the check-completed event. On the action that clears the alarm, write an event whose text says part check completed and whose account field holds the account active at that moment, the one that authenticated in order to clear.
5. Give every operator an individual account in the user list, and retire the shared account or restrict it to setup.
6. Force one alarm, run one check with one account, export the log and read the three rows before you call it done.

What if the shop runs on one shared login?

Then the trail names the group, not the person: one shared account still produces a valid authentication event, and the check record can only ever carry that single name, so give each operator an individual account before go-live.

Count the accounts against the number of people who can clear the check. If one account covers four operators, the best-configured log still reads the same name on every check, and the request is unmet. The identifier can be an employee number or badge ID where names should stay out of circulating files; what matters is that one identifier resolves to one person.

What if the event message cannot carry the account name?

Then the panel cannot meet the request as built, and the honest options are two: route the check through a separate action that does write the account, or record the gap in your procedure and keep a signed paper step until the project changes.

Some projects can write an event on a bit or a button but cannot reach the authenticated user from that event. In that case, make the check its own logged action, a button or a screen the operator signs into, and let the alarm clear follow it. Until that lands, write into the procedure that the alarm history shows the sequence and the timing, and the signature for the inspection is on paper.

What does a complete check look like in a real example?

A 4 minute 7 second sequence with three rows: the alarm at 14:32:05, the operator log-on at 14:33:40, and the check-completed record at 14:36:12 carrying the account that cleared it.

Take a fixture fault on a weld station, with badge 2141 the account on shift. The log reads:

The gaps tell the story. From alarm to log-on: 14:33:40 minus 14:32:05 is 95 seconds. From log-on to check completed: 14:36:12 minus 14:33:40 is 152 seconds, 2 minutes 32 seconds of work on the part. Total, 95 s plus 152 s is 247 seconds, 4 minutes 7 seconds end to end. The check record carries the same account as the log-on and lands 152 seconds after it, so the reading is: this operator, authenticated before the check, completed it inside this window.

How do you test it before the next shift?

Run one forced alarm per account with two accounts: trigger, log in, inspect the part, clear, then read the exported log and check three things, the name, the order and the absence of credential material.

Use two individual accounts and one forced alarm each. After the first run, confirm the check-completed row carries the first account, the three rows sit in order, and no field contains anything that looks like a password. Repeat with the second account and confirm the second check carries the second name and the first run's rows did not change. If the wrong name shows up, the event is stamping the account from the alarm trigger instead of the clear; move the stamp to the clear action and run both tests again.

Where the check state also needs to reach people who never open the panel, a separate shop-floor status screen running your own Android app can carry it to the floor without opening the alarm history to everyone.

Recommendation: log three records per check, the alarm trigger, the operator log-on and the check-completed event stamped with the account that cleared it, and keep the password out of every log, tag and export. Give each operator an individual account and run the two-account test before the next shift. If the project cannot write the account into the check event, close the gap with a separate logged action or a signed paper step, and say so in the procedure.

Questions