The second in a series of articles on the delivery of BMCSs to our clients.
Also read Control System Technologies,
and the series introduction BAS or BS?

Specifying control systems is one of the author's favourite subjects. This does not make him fun at dinner parties. For some reason dinner companions tend to fall asleep when attempts are made to discourse on weaknesses in automation specifications.

Well, there are several things wrong with most control specifications. Working as a control and automation contractor tendering on projects leads to having several concerns with specifications generally. So, what does it take to make a good specification?

It is simple really. Break a spec up into useful sections to cover the following:

• Scope of Work. A short summary of the work that comprises a complete system. 

• General Requirements. Documentation, testing, commissioning, training, computer standards, installation standards, etc. 

• Technologies. A separate section specifically devoted to each technology standard to be provided, such as BACnet, Lon, and/or internet services. The topics for each technology will include networks, panel standards, architecture, operating systems, programming capability, etc. 

• Minimum Requirements. A clearly stated minimum architecture and series of features that must be provided. 

• Project Work. Clearly specifying work for the specific project (points list) and if time permits, a sequence of operation (functional control specification in Australia) 

• Features and benefits. A list and description of the project specific features and benefits required for the client. (These might be included in Minimum Requirements already.) 

• Hard Hardware Specs. A standard for each piece of equipment provided, such as actuators, valves, and sensors.

[an error occurred while processing this directive]Most specifications spend most of their time on hard hardware specs. This is the result of controls contractors offering to support the consultant in writing a specification. They offer reams of paper designed, not to give the consultant a certain quality of system, but a series of bells and whistles that their opposition will find costly to implement.

This is like buying a car and worrying about the quality of paint, the tires, and the stereo. You should be looking at the engine and the steering mechanism. Tires can be changed, the basic functions of the car cannot. And when buying a car, you don't automatically specify the best feature every time. You have to balance cost versus need. This should be true in automation systems.

Simply, if you specify a scope of work, a points list, and the technology you want you will have specified 99% of a system.

Now let's look at the above topics individually. 

Scope of Work 
This is the second most important single paragraph of the BMCS specification (points list is the first). A sample scope of work follows:

This is a list of the general areas of work that the contractor must address to provide a complete system. This list then refers the tenderer to the individual clauses associated with that portion of the work.

The advantages of this approach are twofold. First, it gives the tenderer a single location to review the overall scope of the project. Second, it gives the consultant a quick checklist of the items he requires for a specific project. 

General Requirements 
This is an important section of the specification. Generally though, this is pretty well covered and varies from consultant to consultant, so it won't be covered in detail here. Suffice it to say this should address: 

• Commissioning 

• Installation 

• Documentation for submissions and for manuals 

• Computer and laptop standards 

• Training 

• Maintenance 

• Warranty 

[an error occurred while processing this directive]

Technology
Specifications should have a separate section of the specification to nominate what type of technologies the client desires. These include proprietary, BACnet, LonWorks, Internet interfaces, and client services. Consultants must recognise that control specifications need to be modified for different scales of projects.

In these days of powerful word processing programs, it is a must to have a specification made up of modules that can be pasted together to make a complete specification, much as consultants do with the assembly of the different sections of the specification.

Taking an existing spec and modifying a few words here and there is a horrible approach and leads to arcane references to specific clauses from previous projects.

The last article in this series addressed selection of technologies. That having been said, the technology section of the spec should address the specific technology being requested, plus network construction and the expected performance of the system.

The world is clearly moving to open protocols. If the specification is written to include open protocols, it must have separate technology specs for each of BACnet and LonWorks (or LonMark) if both are to be considered. One specification will not work for both. As indicated in the last article of the series, these two protocols are not interchangeable and do not address the same aspects of control architecture.

Specifically, specifying "BACnet compatible" or "provide an open protocol based system" are a complete waste of time. These clauses mean nothing. 

Minimum Requirements
This is a useful clause to add to a specification. Controls contractors love to bid using alternative technologies, which they consider to be equivalent to the specified technology. As well, they will argue (quite rightly) that the reams of clauses are generic and often do not apply to the specific project being bid.

Putting in a separate clause for minimum requirements forces the BMCS contractor to provide everything noted in this section. This should cover the minimum architecture and technology basis for the project.

As well, here are five clauses that should be in every specification:

1. The client and the client's nominated representatives will be given full and complete access to the BMCS, including all engineering software required to completely program and configure the system.

2. The client will not be liable for any yearly licensing fees.

3. The contractor will provide a written guarantee from the manufacturer that the technology being provided will be supported for a minimum of ten years following completion of the project.

4. All controllers and control power supplies will be located in plant rooms and in dedicated control cabinets, except that they may be mounted directly on the mechanical equipment being controlled.

5. All controls will be powered from circuits dedicated to the control circuit. Application specific controllers that may be powered from the same circuit as the equipment they are controlling, as long as that equipment is powered from a dedicated power source.

Without the protection of clauses one and two, a building owner is going to get raped and pillaged (sorry, there is no more accurate term) by their automation contractor during servicing. The only reasons why an automation contractor wouldn't want to comply with this is because they want to lock the client into a service call every time there is a change to be made to the system, or because the automation system is badly designed and requires different tools to engineer, configure, and operate the system. 

Project Work
Project work is laid out in two manners, a points list and a sequence of operation (or as it is called here in Australia, a return functional specification). Ideally, a project should include both. The points list clearly delineates how many input and output points need to be provided. The return functional specification explains the programming logic required. 

A points list is essential to determine the cost of a project. This tells the controls contractor in clear uncertain terms exactly how many points the controllers must handle, (and hence how many controllers will be required), how many field devices are required, and how much installation will be required. This is 90% of the cost of an automation system. This is the most effective way by far to communicate to the contractor what work needs to be done.

With the powerful programming languages available today, the sequence of operation should not have to be specified in detail for the automation contractor to determine the cost of the project. However, the sequence of operation is still a valuable tool, and at some point the consultant needs to instruct the contractor in the expected operation of the system. Sooner is better than later. But it will turn out to be a wasted effort if the entire system is redesigned, as often seems to happen these days.

A minor specific note. In the commercial controls environment there are two basic methods of programming equipment; block or graphical and line-by-line or basic style. There is no advantage to either and there is really no reason to exclude one or the other. 

The problem with many projects is the lack of time to prepare a detailed sequence of operation. The following generic clause is a useful cheat to have in place for a consultant who doesn't have time to write a detailed description of the sequence of operation: 

3.1 Sequence of Operation 
The controls contractor will allow for programming each point in the points list summary. Allow for programming sequences of operation, alarm points, trend logs, totalisers, and energy management routines.

The contractor will work with the consultant to develop appropriate sequences of operation for all pieces of mechanical equipment. Allow time to develop a customised sequence for each piece of equipment. 

The following sequences reflect specific requirements of this project. It is expected that all controls equipment except application specific controllers will be programmable and that custom controls sequences can be developed for all points listed. Where fixed algorithm controllers are used for repetitive systems ensure that the algorithm will meet the requirements of the project. 

3.2 Graphics Preparation 
The controls contractor will prepare dynamic graphic floor plans showing all spaces on the site and schematics of all controlled systems. Provide intuitive links so that every controlled input, output, and software point can be accessed from floor plan and schematic views. Provide point and click active links from the schematics to access inputs, outputs, trend logs, schedules, alarms, control loops, and any other virtual or physical control points. 

[an error occurred while processing this directive]Features and Benefits
This is the group of clauses that reference the specific features, and hence, benefits, that the client desires for their project. This is kept as a separate section so that it can be modified on a project-by-project basis. Information that is not relevant to all projects will not be found hidden in later specifications. 

Hard Hardware Specification
This tends to be the longest and least important factor in determining the client satisfaction with their automation system. When was the last time you heard a client complain that he only got 3% accuracy on his humidity sensors when he wishes he had 2%. Clients complaints come from the big things, like not having complete access to the automation system or being locked into a proprietary system. Or, not having the system commissioned and programmed properly, which we shall address in a future article.

Generally, a table indicating the accuracy of the various devices would serve to cover most of the requirements of the hardware spec. For example: 
Outdoor Air Humidity Sensor: 2% 
Duct Humidity Sensors: 3% 
Room Temperature Sensors: ±.1°C 
Etc.

Certainly, there is value in specifying exactly what quality of sensors and actuators are expected. However, rarely does this need to be the extensive detailed equipment spec that are found in most specifications. This doesn't hurt directly, but it does tend to removed focus from the important sections of the specification.

Summary
Hopefully these ideas will provide some positive ideas toward specifying automation specifications that are clear for the automation contractor to understand and will ensure that the client and consultant get the system they desire.

Next month we will cover tendering and how the consultant and client can keep control of the selection of the automation contractor to ensure that they are getting the maximum value for money.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]