Smart specifications – How to get what you want, or end up with what you are given?

Mark Cooper of Smart City Products joins The Light Review commentary team.

We all want “the moon on a stick”, but why, when creating a specification for a project or tender do we often end up creating a wish list rather than something that’s affordable, deliverable and meets the projects desired outcomes.

I have seen many, many specifications over my time in this industry, many are fine, but lately there have been some issues that need to be addressed.

With new technologies such as #IoT and #SmartCity sensors being introduced to existing infrastructure such as street lighting columns, often these specifications have been written by asset managers and procurement managers without specific knowledge, understanding or vision to ensure that these specifications are achievable.

What genuinely makes this worse, is that the specifications issued are often copy and paste versions of previous specifications, without really understanding how these relate to their project or if in fact they are accurate or correct. There is no “one size fits all” in Smart Cities, so how can we have one specification that meets all of their requirements?

The London Office of Technology and Innovation has recognised some concerns with IT procurement and, as a result, there’s an appetite to establish some common terms and conditions that could go into every technology-related tender and contract to ensure those shortfalls are designed out of future procurements.

These are:

  1. Services should have an open API
  2. Public data should be public
  3. Personal data should be personal
  4. No advertising (on the services themselves)
  5. Right to data
  6. Easy to exit
  7. Inlusion by design
  8. Secure by design
  9. Seamless user experience
  10. Transparent
  11. No discrimination
  12. Use open standards
  13. No long lock-ins
  14. No bundling

All of these basic requirements should appear in your next IT procurement and you should take specific advice from specialists to ensure we don’t see further examples of the following, which often lead to multiple questions during the procurement stage, Suppliers deciding that the Tender is uncompetitive and can lead to the procurement exercise being abandoned

“Nodes should have a communication reliability of greater than 99%.”later in the document these KPI’s appear“KPI 1, Nodes must maintain a minimum level of 97% across the entire CMS Stock.”

“Automatic Data Collection – The Nodes shall measure electrical values on an hourly basis. Data shall be automatically collected by the CMS every 30 minutes”.Why transmit this data continuously, why not just transmit it once a day but in real time when data is outside of normal values?

“Open Web User interface – To allow for local add-on developments, the CMS shall provide a Software Development Kit to 3rd party independent developers, to add Web Applications in the CMS web desktop/environment, to enable the city to extend the scope of the CMS to other smart devices and other applications.”would thisintroduce security and stability issues? who is checking / approving the code?

“The system shall provide accurate measurement of real energy, power, power factor, voltage, current and other diagnostic information and data using a metering chip facility for all individual luminaires installed and connected to the CMS.

A system that derives the supply and circuit characteristics detailed above from the driver, settings from using pre-set conditions shall not be accepted” – No DALI 2 then?

“Each controller Node shall have a minimum of three stickers with the Node identifier and barcode/QR code. One sticker shall be firmly secured to the Node and the other two stickers shall be removable so that they can be placed inside the column and on required paperwork.” These QR codes often have security details on them such as identifier numbers, MAC id and address, manufacture details etc. useful information for a system hacker, let’s leave them in the bottom of the column where they can easily read them.

From the same specification document, this clause is taken – “Node installation staff shall use an on site installation application via an electronic hand held such as mobile phone or Personal Digital Assistant (PDA) or as agreed with the Project Manager, that records controller Node details, location, asset data, installer data and reports back directly to the CMS.” – Those PDA’s are going to be difficult to use with all those stickers over them!

“The Node shall measure and store the cumulated energy consumption in kWh. The Nodes shall measure and store the cumulated number of lamp burning hours. The Nodes shall be able to report both cumulated energy consumption and lamp burning hours on request” – How long must the nodes be able to store this data? this affects memory size, battery backup, costs and communications. If the Node is transmitting data why store it?

The CMS software shall be provided to meet with the following requirements: “Open technologies – The CMS must be developed with open and standardized languages, for example, LoRaWAN, JSON, RESTful, Java, XML configuration files and SQL database.” – spot the odd one out!

These are just some of the examples i have found, so many more exist – what are your favourites that you have found?

Let me know at

About Mark Cooper

Mark is a past President of the Institution of Lighting Professionals (ILP), the UK professional membership organisation for lighting. Mark has held other roles within the ILP, he serves on the Editorial Board for the Lighting Journal and has previously been Senior Vice President and Vice President for Membership.

He has over 27 years of experience within the lighting industry, working in a number of roles from local authority lighting engineer, through Sales and Product Management and as a Divisional Director for Jacobs Engineering Inc before moving back to a manufacturer.

Mark was National Sales Manager for iGuzzini, responsible all outdoor lighting sales within the public realm, and promoting their new road and street lighting ranges, then moved to DW Windsor Ltd as their Technical Manager and developed a number of product ranges and sensors for both DW and their sister company Urban Control

Mark recently started his own consultancy business specialising in advice for Local Government and Manufactures in the emerging market of Smart Cities and IoT an area he has worked in alongside lighting for nearly 15 years. He has presented a number of seminars at National events Mark has been key in selecting, developing and deploying a number of large scale CMS projects in the UK during his career and written many articles for the UK trade press about this subject.

Visit Website
View All Posts

The Light Review Newsletter

* indicates required

Please confirm you'd like to hear from The Light Review by email:

You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please visit our website.

Latest Articles

Scroll to Top