There’s been a lot of talk in the industry recently about the apparent benefits of running open protocol controls on your smoke control system. And while that sounds like a good idea and is surely a worthwhile cause worth championing, we’re forced to ask the question: what control protocols in the real world are actually truly open?
What’s the difference?
The traditional argument – oft trotted out in this industry – is that closed protocol systems offer ease of use and reliability and that open ones offer versatility and accessibility, with a more free choice of components and more ability to make the system flexible and adaptable.
While certain aspects of this position are certainly true, we do have to take issue with the part about flexibility and adaptability. Sure, an open control protocol may let you add in new components from different suppliers etc, but is it truly open?
There’s a case to argue that any conversation about open protocols is misleading full stop, as it does not address the issue of IP (intellectual property) owned by the controls’ original software developer.
Although we at Adexsi UK are all for the principal of open protocol controls, the reality is that this is simply not enough – it’s of very limited use if you do not have a copy of, or permission to modify, the original code.
Controlling the controls
As far as we’re concerned, when we’re working on a smoke control system we want to be able to make it do whatever we want. If the cause and effect needs to be brought up to date, or if new technology is in use among the many components of the system, then the controls will require significant updating. A mere password into the control panel won’t offer anything like the level of access required to make such changes; a truly open protocol supplier would provide access to the actual code in use and therefore allow for reprogramming of the system’s core functionality.
Surprise surprise, that is not the case.
Making the best of it
From our perspective as maintenance providers to smoke control systems, this leads to difficulty in properly managing such systems in the flexible, real-world environments represented by our various service customers.
Without free access to the original code and developer tools, the best-case scenario sees us being forced to use the same, pre-installed hardware and rewrite new software from scratch in order to achieve the safest, most effective results. Needless to say, this is extremely expensive and time-consuming and means we have to undertake a huge amount of work to mitigate the significant risk of missing something that was crucial – but perhaps not obvious – in the initial system design.
So, next time a supplier tells you all about the benefits of their open protocol control system, ask to see the code and see what happens…