Tomorrow's Engineer: Turning The Century
It's All Part Of The ProcessWhen working at this firm, I was assigned the task of managing the BAS group. I was not a control engineer by background, and although I could write my own sequence of operation, I believe the assignment was based on my ability to manage people and manage the process, with "the process" being the key term.
I was clueless to the electrical and electronic terminology and building automation design that makes up DDC systems, so I relied on a select few BAS engineers and technicians to check each other's work. However, the process I could do, and I started out focused on learning how we provided BAS services. I began with how we created a scope of work and how we priced up a D-B control job.
Following the process' trail, I created a flow diagram/roadmap as I continued on with my BAS business education, enhancing the flow diagram as I went. Within a few days, I had a clear understanding of how we did designed and built BAS and could now begin to analyze the process and propose improvements to this process.
Our single-source solution was to first understand an owner's needs, and then to produce a scope of work with project estimates that would take us through design, purchase, and buyout of equipment, materials, and labor, installation, points checkout, and commissioning of the system prior to project turnover and closeout of the job.
Improvements Borne Of ExperienceWith this experience, I now had three suggested improvements to the current BAS project process: complete the system programming immediately following the acceptance of the sequence of operation; be specific when requiring BAS trending capabilities; and specify predictive maintenance instead of alarms.
Complete the system programming immediately following the acceptance of the sequence of operation. It has been my experience that today's control companies will submit the sequence of operation submittals to the designer and then do nothing with the completion of the system programming task, putting this need off until much later in the construction schedule, with the final programming being input around the same time this firm is trying to complete all its on-site work while the commissioning firm is looking over its shoulder. As a result, the control contractor finds herself behind the project schedule, with startup and system demonstration flawed. My answer to this dilemma is to insert into the automatic control specification the following:
Immediately following the acceptance of the automatic control submittals and no later then 60 days after submittal acceptance, this contractor shall submit the system programming/logic flow diagrams. In addition, this contractor shall include at this time the system checkout checklist used to verify system performance and interaction.
Be specific when requiring BAS trending capabilities. This specification requirement is often misunderstood when inserted because the BAS technician on the job site will say that the computer can do trending and no one has asked for any specific trending. If we were to go back to that antiquated BAS specification that says (or implies) the control system shall be capable of system trending, experience has shown that yes, the control system is capable of performance trending, but since no specific trending was specified and the control contractor is now rushing to complete the job that is behind schedule, no trending is done. The solution is for the specification writer to be more specific when requesting trending in the BAS section of the specification. Try the following:
This contractor shall have the system trending activated for the following system points: "Insert the list of trends required." Trending shall begin one week prior to this contractor demonstrating the functional performance test required by the commissioning firm and continue on for a minimum of one week or longer based on the owner's facility management and after system demonstration and acceptance.
Specify predictive maintenance instead of alarms. What good is an alarm if there isn't an action plan to go along with the alarm? Does the designer really want the facility operator to receive numerous alarms, or is the intention to react to an action such as the filter differential pressure across the filter indicating that the filter is dirty? Wouldn't it be more useful to signal the BAS operator that the filter is reaching a point in its performance that will require the filter to be changed? The predictive maintenance solution is to signal a workorder, not an alarm. ES