How TALQ Functional Test Cases Ease Investment Decisions of Cities

Smart city procurement often fails not because cities lack ambition, but because they struggle to translate that ambition into precise technical requirements.

In outdoor lighting, this problem is especially visible. Cities are asked to make long-term infrastructure decisions involving control systems, gateways, sensors, dimming programmes, alarms and maintenance workflows, often through tender documents drafted by teams that may only face this type of procurement once. The result is a familiar risk: systems may be certified, modern and technically capable, yet still not support the specific functions a city expects in practice.

This is the challenge TALQ was created to address. Founded in 2012 by major lighting industry players, the TALQ Consortium set out to define a standard protocol for outdoor lighting interoperability, helping cities and utilities future-proof their infrastructure choices regardless of supplier. Since 2017, TALQ has certified solutions that successfully integrate the protocol, giving decision-makers a clearer basis for comparing systems and reducing procurement uncertainty.

In this interview, José Sanchis, Chairman of the TALQ Certification Workgroup, explains how functional test cases build on that mission to make the creation of city-specific lighting requirements easier and more complete, while helping municipalities compare systems and make long-term investment decisions with greater confidence.

TALQ at a glance

Now it is nearly ten years since the TALQ Certification became a well-known criterion for cities when planning a new street lighting system. Why did you feel the necessity to introduce the concept of the ‘functional test case’?

José Sanchis: Over the past years, market feedback has shown that choosing TALQ-certified products alone does not solve the challenges of cities sufficiently. We were approached by several cities that found out – at a very late stage in their selection process – that the systems they wanted to combine did not match sufficiently with their individual functionalities. At first, we were surprised, as the provided data for TALQ-certified products, a very detailed capability list for each system, does contain all the necessary information. However, upon closer examination, we realised that cities choosing new lighting systems face numerous decisions early in the process, without having the experience to define requirements that accurately reflect their use cases, let alone compare the complex and highly detailed capabilities of each product.

To solve this problem, we developed our TALQ functional test cases, a set of easy-to-understand business-relevant tests that hide the complexity of the certification process and that cities can refer to in their specifications and tender documents.

So, the functional test cases are not only related to TALQ certification (existing or not) but can be thought of as a tool to help cities define their wish lists?

José Sanchis: Exactly. Before introducing this concept, ambitious cities made the effort to compare hundreds of detailed features, but often lacked a clear overview of the consequences in case one or more functionalities were not included. When we started to develop our functional test case concept, we took the perspective of a city representative who wants to describe a best-fit outdoor lighting system. In the end, we were able to reduce the complexity to only 43 potential use cases for public lighting, grouped into five categories: Configure, Monitor, Control, Program and Alarms.

Additionally, we changed the previous very technical descriptions to an easy-to-understand language. For example, instead of saying “The Gateway starts bootstrapping…” we now say “The Gateway successfully connects…”.

Can you give us an example of a basic functional test case and of one individual ‘nice-to-have’ case?

José Sanchis: One of the typical functional test cases for a TALQ Gateway, requested by virtually all end customers, is “CONFIG-1: Connect to CMS and announce light point control capabilities”. This functionality guarantees that a Gateway and a CMS can communicate and defines which data is transmitted.

An example of a functional test case that not all cities may require is “PROGRAM-6: Support special date ranges (seasonal exceptions)”. These special programming features require end users to define and manage precisely calendars and exceptions throughout the calendar year.

How did cities and other stakeholders react to the definition of functional test cases?

José Sanchis: The market feedback was very positive. Our members also reported that, in recent tender negotiations and implementations, end customers have a much clearer understanding of what to expect, and what they observe during their own deployment aligns much more closely with those expectations than before.

This is also one of the reasons why we, as a Consortium, will begin developing functional test cases for other TALQ Profiles beyond Lighting, such as Cabinet Control, Environmental Monitoring, Waste Management, Asset Management, etc.

Summarising the actual situation, on average, how many functional test cases does a certified product cover?

José Sanchis: On average a TALQ-certified product might cover 50% of the 43 functional test cases for Lighting, with approximately 60% of products covering close to 70% of the test cases. However, the range is very broad: some products cover all functional test cases while others fulfil only one. Whatever effort we make to improve our descriptions, we cannot – and we clearly do not want – to provide any pre-selection advice for end customers. Instead, we continue to focus on increasing transparency.

At the same time, manufacturers of TALQ-certified products need to make sure that optional features are also included if they want to improve interoperability. Likewise, decision-makers in cities and utilities need to have a clear understanding of the minimum requirements their future lighting systems should meet.