An RTC IC can support time-stamped records, but selecting a clock is only one part of designing an auditable system. A useful record must explain what happened, which device or user was involved, and whether its time information was valid. The hardware, firmware, storage and operating procedures need to work together.
This article focuses on engineering checks for timekeeping and event records. Requirements for a particular regulated application must be defined and reviewed separately; no RTC part number alone establishes compliance.
A timestamp is not the complete audit record
A local clock provides a time value. The application decides which event to record and how to associate that value with the event. It also determines whether users can change the clock or alter, delete or export stored records.
An ordinary RTC does not make a log tamper-proof. Clock accuracy and record integrity are separate requirements. Specify the controls needed for time changes, record access and data retention at the system level, then verify their implementation.
For example, an equipment log may need a device identifier, event code, sequence number, timestamp and time-validity flag. Those fields help reviewers interpret the record, but their presence alone does not prove that the underlying event was captured correctly.
Define what the time value means
Document the time reference used by the device, how it is initialized and when it is synchronized. Decide whether records store UTC or another documented convention, and how local time is displayed to users. Test daylight-saving transitions where they affect the interface.
Define the acceptable timestamp error for the actual use case. Calendar resolution, oscillator accuracy and the delay between an event and its timestamp are different contributors. A clock displaying seconds is not evidence of millisecond event accuracy.
If an external service updates the clock, specify how the system records that adjustment. Preserve enough information to interpret event order when a clock moves backward or forward.
Treat loss of valid time as an observable condition
A backup supply can maintain supported RTC functions while main power is unavailable. It does not necessarily power the processor, sensors or storage, so it does not by itself ensure that events continue to be recorded during an outage.
TI's BQ32000 product information provides one example of a serial RTC with battery backup, trickle charging and oscillator-fail detection. Review the exact device data sheet for supported functions and their operating conditions. Failure detection should be connected to meaningful firmware behavior rather than ignored.
Check what the application does after backup depletion, initial installation, clock reset or an oscillator fault. Mark invalid or uncertain timestamps clearly and define how normal recording resumes after time is restored.
Verification evidence to retain
- A timekeeping requirement that states the acceptable error, operating conditions and reference source.
- The selected component documentation, circuit configuration and relevant firmware version.
- Test results for startup, power interruption, backup depletion and restoration.
- Tests showing how authorized time changes are recorded and how unauthorized changes are handled.
- Evidence that exported records preserve timestamps, identifiers, event order and validity information.
- A documented process for investigating clock faults and assessing affected records.
Use representative hardware and realistic operating conditions. Keep the procedure and measured results together so another reviewer can understand what was actually tested.
Component selection and procurement
Compare the required interface, supply range, temperature range, accuracy and backup behavior against the exact orderable part. Treat alarm, calibration, failure-detection and security features as device-specific capabilities. Do not assume that every RTC includes them.
For an Informic sourcing enquiry, provide the full part number, quantity, package and application conditions. Confirm availability, traceability and order terms before approving the proposed supply.
