TECHNICAL FEATURE have, and it is an absolute nightmare. Clients rely on information for validation, compliance, and post-event analysis. It is downright scary how many systems in the field provide audit and database access to all users. This is not something a design engineer typically thinks about. First, we must identify the issues: Are you trying to achieve database redundancy? Does your client need to be able to perform compliance reports? What are you trying to achieve? System design typically falls into three categories. Category 1: Audit Files. A 21st century system needs to have a 21st century specification. This means that you must specify the level of security for the audit system. Doing this will ensure that if a mistake is made the employee can't simply go into the audit trail and delete his mistake. I cannot emphasize how many times I have seen operators make mistakes and then delete these mistakes from the audit trail, sometimes right in front of me! How do you write this into a spec? The following language tends to work quite well. Spec it Out 1. The BAS software will provide an audit trail that logs all user actions and can only be read and/or modified by a system administrator. 2. This audit trail will show the administrator, what system was modified, the value modified, and the time of modification. Category 2 Database Capacity. A system is only as good as its database. You wouldn't deposit your money in a bank that regularly wiped your account statements due to "data storage concerns." So why do we install control systems that can only store 30 days' worth of data at one-hour intervals? The typical answer is it costs more, but does it cost more? Let's dig into this. www.info.hotims.com/49808-29 62 ASHRAE JOURNAL ashrae.org SEPTEM BER 2014