Specification Do’s & Don’ts
There are many different styles of specification and obviously writing a catch all for every type of specification is going to be difficult if near on impossible, so I have taken the middle ground and tried to outline some of the common challenges the lighting and controls industry faces and also sometimes continues to make through dated practices.
In a very simplistic overview the specification should provide a framework of what the project is attempting to achieve and as a minimum provide a performance specification of how the building should operate.
As a lighting engineer I will focus primarily on lighting, but the principles are the same regardless of the industry.
Firstly, no one knows what they really want and that is the problem especially with all of the hype surrounding certain technologies. We all think we need the latest gadget or widget to make us more efficient but often it’s not appropriate to how the building is being operated and can in certain instances work against what you're trying to achieve.
Therefore, the first challenge is understanding the client brief. It's worth mentioning that their expectations often don’t match their budgetary restrictions so compromise will have to be agreed at some point; however, it critical at the design stage to understand the client’s needs; actual and aspirational.
Once you have this data then it’s a case of how you convert this to a meaningful set of achievable goals. These should be split into different categories such as:
Compliance;what do I legally need to deliver to ensure I cover my design responsibilities. Frankly this is fairly straightforward and providing you provide sufficient illumination and have some level of control then you will have met your obligations regarding lighting the space. A word of caution, good lighting design should be vigorously defended as lumen output is no measure of optical performance or scheme performance. A wooly specification at this point leaves the design open to interpretation and as a consequence value engineered for often inferior lighting solutions.
Emergency lighting also comes under this heading and this is an area that does need to be independently specified as this is a life safety system and compromising emergency performance can have serious implications. Always, automate the emergency testing of emergency lighting, as manual testing isn’t adequate and cannot be defended in a court of law. Automatic test system provides certified test and monitoring data that ensure compliance.
Scalability:In the real world we construct buildings floor by floor or even room by room so your controls system should be designed to provide a flexible infrastructure that doesn’t require dated technology such as area controllers which hark back to legacy system twenty plus years old. If the infrastructure costs are substantial, then you should reconsider that provider as systems such as the zencontrol platform are based on an open platform of independent application controllers; in various form factors that provide a seamless integration for DALI-2 compliant lighting and controls. Out of the box you have full functionality of control, with management available through the IP backbone once installed; also its worth mentioning that it doesn’t need that backbone to function.It’s worth stating that DALI-2 should be the base line of any controls system currently being installed as it’s a defined standard IEC 62386 and has been designed to be scalable from the outset.
Upgrade:similar to scalability, however, the danger with the older control systems is the lack of upgrade path and this works against the principles of the connected world. Various terms are used but the most common is the Internet of Things IoT which is a catchall for connecting disparate devices onto a common wired or wireless platform. DALI-2 has been designed to be upgradable through life and with the addition of IEC 62386 Part 104 this year we will see the integration of wireless to DALI-2. In the real world you will have multiple systems on a project so it’s important the control system is open and interoperable with other systems. This is the premise behind the zencontrol platform and should be the same for all lighting control systems. Crucial to good specification is the process of revue and amend/ update. I’m more than happy to help in this area.
Integration;how can you integrate the lighting management system into the wider building controls platform. This is critical if you are to achieve any degree of scalability or upgrade as the future of lighting is focused on connectivity and I am at a loss as to understand why anyone would specify any legacy control system that is locked down by the manufacturer. An open system gives you the freedom to adjust your design and add features during the design phase as well as in operation without penalising the building owner or operator. Any system that insists you have to buy their particular switch or sensor is limiting the functionality of that system and ultimately having a major impact on the Operating costs.
Software will also play a major part in the specification process along with security of the system and these are topics that require a good deal of attention. The legacy systems are closed for a number of reasons and some of this may in part be due to the lack of security built into the system. Technologies such as wireless communication offer a number of advantages and will be a main stay of future lighting control systems, so upgrade to wireless is critical, especially with the publication of IEC 62386 Part 104. Part of the delay within IEC for the publication of this upgrade to DALI has been the issue of security. DALI-2 is a completely different system to the DALI of old and as such intelligent sensors and switches along with wireless versions of the same will co-exist on multiple networks and that integration has resulted in some very clever security parameters. At zencontrol we use enterprise levels of encryption to ensure devices added to the lighting control system are fully compliant and have the necessary security features to maintain the integrity of the overall system. Part 104 compliant devices meet these criteria so it’s important you validate and authenticate any wireless controls.
There will be occasions when a gateway module may be used to connect to a different wireless protocol and that’s perfectly acceptable providing this is supplied via a reputable manufacturer with the appropriate levels of security.
What does worry me, and this is again down to specification is the term equal or approved. DALI-2 equal or approved products are third party tested and will work together, however a system from an unknown manufacturer may not.
Value engineering is only possible if the specification is not detailed and parties can provide solutions that on the face of it are compatible but in reality, are not. A mistake in selecting a budget wireless device could compromise the security of the whole network. As a consultant engineer or designer, you must consider risk, and this is why you should always adhere to known standards and best practice. Failure to do so compromises your design and robs the end client of the potential that system may have delivered.
I appreciate its difficult specifying controls and that is why we are here to help you. At zencontrol we have a range of tools and processes that help you to deliver a lighting control specification for today and the future.
If you want to talk more about this or would like me to present my CPD on How to Specify Lighting Controls, then please drop me an e mail or give me a call. I am happy to present this via Skype so if you’re an international practice then again please drop me a line to discuss your controls specification.
Stewart B Langdown FSLL
m: +44(0)7774 821093