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.
- Services should have an open API
- Public data should be public
- Personal data should be personal
- No advertising (on the services themselves)
- Right to data
- Easy to exit
- Inlusion by design
- Secure by design
- Seamless user experience
- No discrimination
- Use open standards
- No long lock-ins
- 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 email@example.com