For many years we have been told that street lights are foundation to build upon for smart cities, there are good reasons for this, they are convenient power sources placed at regular intervals throughout the city and are high enough to place sensors out of reach and give good coverage and clear lines of communication for wireless devices. However, are both industries going in the same direction, or going their own ways?
Within the IT industry we have seen a move towards collaboration, and merging of different systems and protocols to allow mass sharing of data across different platforms, giving the end customer a choice of solutions and not binding them to sole suppliers. Many examples of this exist in IT - google maps on apple phones, opening and editing a microsoft word document in google docs and Linux programs running on a windows laptop. We have understood that we need to use open standards and open protocols to allow data to be shared and communication to be widespread.
So, why is it then, that the lighting industry is developing specifications and standards that effectively restrict sensor development to a single power source and a communication protocol that tries to place sensors into a defined container which restricts innovation and features. We want the IT industry to adopt our standards and make sensors that fit into these containerised views and change everything they do and know is right in order they can be fitted to streetlights.
The D4i and Zhaga Book 18 specifications are a great step forward for lighting, particularly in a building, but do nothing for a Smart City deployments.
With restrictive data profiles, power management and physical connection, these standards try to impose a blinkered approach to Smart Cities where the street lighting industry believes it can drive multinational companies and industries to change their direction just to make use of the convenience of a street light!
It's the same with software, CMS companies are promoting the use of TALQ to ensure that systems can be "interoperable" and that end users can install hardware from various suppliers on various networks but see data on one piece of software. Sounds good in principle, but the practical application of this is that it's just not that easy.
We already have a number of standardised solutions to sharing data between software platforms and cloud based services such as open and published API's, so why do TALQ have to "invent" another system and then hide the specification behind a paywall, only open to their members, and apply this to not only software and server level interaction but also at hardware level at the gateways? Can anyone explain to me what TALQ 2 does that can't already be accomplished with good software coding using published and open standards?
Additionally, most specifiers, don't know what TALQ 2 is, what its aims are and why they need it? One of the aims of TALQ 2 is stated as "vendors are free to describe their devices using TALQ functions that include a set of agreed configuration, operational and metering attributes and events, which can be configured, controlled, commanded and monitored using TALQ services." and "enables vendors to describe any type of device using functions, attributes and events, in a way which is easy to understand for Central Management Software."
Many people have taken this as being able to display sensor data within the CMS software, this would be wholly impractical and a pointless exercise for a Smart City project. CMS software is command and control plus asset management data. The data produced by IoT sensors needs to be analyzed, visualised, distributed and acted upon by many different people within the organisation and this requires a different type of business intelligence tool, not a simple asset management software platform.
There is a way to implement Smart Cities using good industry open standards, partnerships and having a clear vision of what data will be produced and what its likely to be used for and by who.
Don't get seduced into specifying standards developed by a lighting industry that is struggling to come to terms with the fact they have moved from a metal bashing industry, to an electronics industry and on into a digital industry within a few short years.