14.10.19

Driving quality in control systems

Programmer 1
Golubovy / Shutterstock.com

One of the most frustrating parts of the job in delivering robust control system solutions often come about when the system you’re configuring requires a great piece of technology and the manufacturer has given fair consideration to the custom integration community and provided a published API. That’s all good, until you find that there isn’t an integration module for your platform. Or you have a simple control scenario of a display and a few simple sources that’s been working perfectly for a year, when the client swaps the display for a different brand.

Until recently, the only way to solve these problems would be to fall back on traditional programming paradigms and roll up your driver-writing sleeves, or crack open the program to replace the hardcoded device driver for the new display. If you’re a programmer for systems that require more sophisticated customisation, this is often the most viable option. But a lot of integrators today – both residential and commercial – are looking for ways to deliver systems more quickly, and with as little support burden as possible. Rightly or wrongly, “programming” is generally the first thing in the gun-sights for any issues reported. 

For a large proportion of control system projects, the client doesn’t need (or care) about the bells and whistles we’ve laboured without sleep over for the past six months – they just want to watch TV or make a VC call, reliably, easily, have it work every time, and be able to do that without wiping out this year’s profits. 

That’s the reason that large control systems providers, like Crestron, are looking for any way to have their systems deployed and functioning without the need for bespoke software development. What clients may lose from a lack of customisation or being able to satisfy (sometimes poor) requirements has a significant up-side though. Configured systems re-use the same code over and over in varied scenarios and as the platform matures it becomes more likely that someone else (hopefully the developer’s own quality assurance team) will have found any functional defects and fixed them. That leads to higher confidence in a deployment “just working” and fewer profit-absorbing in-warranty service calls. 

This is, of course, all anathema to us (Ultamation) who have built a business around providing Crestron solutions to clients and charging for our professional skill and expertise. How are we going to make a living in this new menu-driven world of system design? 

Fortunately, as with many technological shifts, there’s almost always more opportunity created than taken away, and we’re confident that this transition will be no different. And while it doesn’t help with poor terminations, more code re-use can only be of benefit to software quality.

Programmer 3
Monstar Studio / Shutterstock.com

One of the corner stones of a configurable control solution platform is a pluggable driver framework. What this means is that you find all the things that particular types of devices have in common, boil them down to a set of templates that satisfy all of the essential common functions for those device types and provide a software development kit that allows anyone to build a driver that complies with one of the standard templates. 

For example, a Sony projector, a Samsung and a Panasonic display walk into a bar… sorry… I didn’t mean that. They all share, in their primary function, the same common requirements – you will turn them on and off and you will select which input they should display. In this overly simple example, our “display” plug-in template will expose those functions and we don’t care how the particular display gets told what to do or even how it’s connected up – it could be IR, serial or IP. It’s then down to control system programmers to write a device specific driver (Sony, Samsung, Panasonic, etc.) that satisfies the display template. These driver implementations can then simply be plugged into the control platform and we have a functional system. If the client swaps the display from Sony to Samsung, switch the driver, and the job is done.
 
There will always be systems that cannot be constrained to fit the generic templates – things like divisible rooms, multiple displays, car turntables(?!) and so on – and that will mean that we programmers are not an endangered species. The opportunity of writing drivers for the integrators who don’t possess the in-house programming chops to write their own drivers has allowed Ultamation to expand its business model to create new revenue streams that nicely fill the troughs between the inevitable “peaky” nature of residential automation project delivery. 

Programmer 2
Alpa Prod / Shutterstock.com

Over the past few years, Crestron has been developing and refining their Crestron Certified Driver (CCD) framework. While it doesn’t cover every device type, we already have templates for displays, set top boxes, AV receivers and Blu-ray players, and there are a number of other templates in the pipeline which will, we understand, eventually cover everything from security systems to lighting to heating. 

The CCD software development kit (SDK) is available to any certified Crestron programmer with sufficient knowledge of C#. While the concept is simple, Crestron have created a sophisticated platform that makes implementation of simple protocols trivial, yet still allows for the expression of more complicated protocols that require bi-directional communications, authentication or higher level transports such as HTTPS. 

Ultamation has been working with the CCD SDK since it was originally released for evaluation by Crestron (under the name of Rapid Agile Drivers) and we’re proud to be the first third-party driver developer to release a Crestron Certified Driver for use with the Crestron Home (OS3) and Pyng (OS2) allowing integrators to control Sky Q and Sky+HD boxes over IP, and finally ditch those IR bugs.