The deployment of coherent, interoperable smart street services that are seamless for users is built around the use of common norms and ways of working – this is generally achieved through the use of standards. This section provides a brief introduction to the use of standards and how they fit into the specification, procurement, and deployment of smart streets.
Where choices exist, suppliers typically promote solutions that complement their technical solutions and business approach. These are not always complementary or interoperable with others. Hence technical and management standards are defined and used to create commonly agreed ways to achieve certain activities or to support interoperability and interchangeability of data, system components, etc. Due to the breadth, diversity, and complexity of smart streets; many technical standards exist covering different domains, technologies and interfaces and diverse stakeholder communities.
On first introduction, the landscape of existing technical standards supporting smart streets can be bewildering and challenging to navigate. This landscape is not static and evolves over time and is complex. There is no “masterplan” or complete model that explains which standards to use and under what circumstances, or how standards relate to one another. Adding to this complexity, there are several regulations, often calling upon European or British standards (e.g. for electromagnetic compatibility, radio transmissions, or safety) that must also be considered.
There are however some useful resources that this guidance points to. These are detailed later.
In some complex and rapidly developing parts of the landscape, authorities should consider the benefits of seeking expert assistance to ensure that the landscape is appropriately understood, correct standards are referenced, and specification and procurement processes are efficient and correctly targeted.
An Authorities procurement of systems and services is typically done against a specification requesting defined capabilities. These capabilities may include target inputs and outputs (for example, defined formats and content of reports, or support for web-based end-customer facing services) and should concentrate on the “what” the systems and services should do, not “how” they should do it. Such specifications generally include the ability to consume, use and output, certain forms of data as well as normally a range of non-functional requirements. Non-functional requirements may include aspects relating to:
It may be easy to say that no single standard defines fully what is going to be required in any Authority specification for services or systems. However, what should be considered is how interoperability is achieved through standards, and a bi-product of that is the need for common functionality. Defining standards may provide a means of assurance for the Authority procurement by providing a baseline for interoperability and common functionality.
If referring to a specification, the Authority should take care to be clear about how the referenced standard(s) are intended to be used. It may well also be part of the procurement process to define quality and assurance procedures to state how conformance to a defined standard will be assessed. This may be done by supplier self-certification or a declared process for shared visibility testing – see below.
A wide spectrum of standards exists. Some may be mandatory to meet UK government Regulations. Many have direct relevance to Smart Streets. Many only have touching relevance.
There is no universally agreed “standard” definition of what a standard is, nor a definitive agreed list of the bodies that create and publish them. However, not all claimed “standards” are equal. Hence this section provides a high-level overview of the standards relevant to Smart Streets.
In very general terms, most definitions of a standard have some common characteristics. Standards:
There are extensive policy papers and research supporting the stated benefits of using widely available standards. At the highest level, these are normally stated as:
For an Authority, the use of and reference to a standard supporting Smart Streets offers the following benefits:
Reduces the need for the Authority to necessarily be “expert” in all requirements for a Product or Solution being specified (as these will have been elaborated within the standard).
Various legislation and associated national policies are relevant in instructing the use of standards in smart streets. This section provides only outline guidance.
Public sector procurement is subject to a legal framework which encourages free and open competition and value for money, in line with internationally and nationally agreed obligations and regulations. The government aligns procurement policies with this legal framework, as well as with its wider policy objectives.
UK Legislation remains aligned to the EU. Three directives are relevant:
Public procurement is also subject to the World Trade Organisation Government Procurement Agreement.
Once the 2014 EU Procurement Directives came into force, the implementation of the UK Public Contracts Regulations 2015 took effect from 26 February 2015.
This defines financial thresholds and the procedures laid down before awarding a contract to suppliers. However, the threshold contract values for Authority goods and services is higher as explained in Procurement Policy Note 04/17.
Procurement policy includes the use of open standards. For more information see below.
There are a range of legislative acts that place duties on authorities, in relation to smart streets. This section does aim to provide a complete coverage of these, but highlights some of the most significant legislation. Many of these duties are not expressly related to the use of technology in smart streets.
The Transport Act 2000 gives local authorities the duty to develop policies for the promotion and encouragement of safe, integrated, efficient and economic transport to, from and within their area, and carry out their functions so as to implement those policies.
With transport encompassing:
These duties shall take into account any policies announced by Her Majesty’s Government and have regard to any guidance issued by the Secretary of State.
The New Roads and Street Works Act (NRSWA) 1991, with further amendments in 2016 and by the Traffic Management Act 2004, and supported by relevant Regulations and Codes of Practice: provides a legislative framework for street works by statutory undertakers (including utility companies) and works for road purposes – to the extent that these must be co-ordinated by street authorities. The use of NRSWA is linked to the DfT’s Street Manager service., see 7.1.
The Traffic Management Act 2004 Part 2 lays down duties for local authorities in respect of the movement of traffic:
The Local Transport Act 2008 makes further provision in relation to local transport authorities, the provision and regulation of road transport services and the subsidising of passenger transport services.
The National Street Gazetteer (NSG) is the definitive reference dataset of streets within England and Wales used for street works, highways maintenance and traffic management. In line with British Standard BS 7666(2006) the NSG is regularly updated by all 174 highway authorities with Additional Street Data (ASD) such: as road centre lines; ownership details; level of reinstatement required; height,weight, and width restrictions; and permitted routes.
The Traffic Signs Regulations and General Directions (TSRGD) 2016 is the statutory instrument that prescribes the design and conditions of use for traffic signs: including sign plates, road markings, and traffic signals, etc. Furthermore this prescribes the regulations to users conveyed by these traffic signs.
The Construction (Design and Management) Regulations 2015, commonly referred to as CDM regulations, set out the law for managing health and safety in construction. These regulations place specific duties on clients, designers and contractors, to manage health and safety for the whole construction process from concept through to decommissioning. These replace previous CDM 2007 regulations.
HM Government has published policies and guidance (Public procurement policy – GOV.UK (www.gov.uk)) on public sector procurement policy particularly with reference to open standards with respect to Information Technology solutions. (https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles). This notes that open standards principles should be adopted on the use of open standards to make government IT more open, cheaper, and better connected.
When specifying requirements for software interoperability data and document formats the public sector must request that open standards are employed and these conform to the definition described in the open standard principles or adopted subject to the principles of equivalence. The use of compulsory open standards profiles have been adopted for the use in government subject to a “comply or explain” process.
Procurement Policy Note 07/15: open standards for technology states that open standards give users permission to copy, distribute and use technology freely or at low cost.
Open standards must also be:
For local authorities, a key duty is set out defining the requirement to establish a local transport plan. New government guidance on local transport plans is currently being drafted, which could place a burden on councils to decarbonise or risk losing funding. The Department for Transport has indicated spring 2022 for the release date of the guidance, which would replace the existing framework published in 2009.
The Clean Air Strategy 2019 sets out the Government’s approach to clean air improvements, and sets out a wide range of proposed actions to tackle all sources of air pollution. This sets out in detail how devolved administrations intend to make their share of emissions reductions.
General standards that are widely known may be applicable to the delivery of almost any smart streets system or service. Well known ones include:
The design and implementation of highways and streets are defined by some well-known maintained manuals.
The Manual for Streets (MfS) focuses on lightly-trafficked residential streets, but many of its key principles may be applicable to other types of road, for example high streets and lightly-trafficked lanes in rural areas. The MfS is used predominantly for the design, construction, adoption and maintenance of new residential streets, but it is also applicable to existing residential streets subject to re-design. MfS is not intended to be applied on higher speed trunk roads. For further information on the MfS see https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/341513/pdfmanforstreets.pdf. The MfS is maintained by the Department for Transport.
The Design Manual for Roads and Bridges (DMRB) is intended to be applied to motorways and trunk roads. For further information on the DMRB see https://www.standardsforhighways.co.uk/dmrb/. The DMRB is maintained by National Highways in conjunction with the nations’ Overseeing Organisations (Transport Scotland, the Welsh Government, and the Northern Irish Department for Infrastructure).
It is worth noting that DMRB is often considered to be the de-facto good practice for local roads with some exceptions where there is a good reason to depart from DMRB.
Standards published by some organisations such as BSI (British Standards Institution), CEN (the European committee for standardisation) or ISO (the International Organization for Standardisation) can have relevance with public procurement.
The spectrum of formally recognised Open Standards covers a wide spectrum of domains. Additionally, numerous standards relate to the application of specific technologies, common terminology, and architectures.
To support the standardised exchange of data, numerous standards for data encoding exist. Almost all instances of these transport-oriented standards, are based on and utilise more generally applicable generic mechanisms for data encoding, data modelling and mechanisms for data exchange drawn from the wide IT, communications, computing and data industries, for example:
It is important to differentiate the way data is sent (a data exchange protocol) from the data that is sent (payload). For example, DATEX II defines standard traffic information as a payload but can be sent in a variety of standard protocols (e.g. XML, JSON and ASN.1). Specifying one protocol alone is not enough. It is also possible for proprietary information to be the payload in a standard data transmission network.
Some of these families of standards have been developed by specific stakeholder communities for particular domains of application in smart streets. Many public transport practitioners will be familiar with the European TransModel/NeTEx/SIRI series of standards; likewise the DATEX II standards are widely known for the exchange of traffic management information payloads. The use of these standards, and others, is often set in a context for more specific tailored use in the UK. Further information is given below.
There is a long-standing tradition of collaborations between industry and some times public sector actors to develop and self-publicising their own standards. The nature of these collaborations varies considerably. In some instances, the collaborations are long standing, well organised and supported by robust, mature processes and stakeholder communities. Others are much more temporary, and light-weight. These industry collaborations may call upon many business models, some of which may only arguably create open standards.
However, many industry specifications and standards emerge from such entities, which can benefit from more nimble, lightweight and quicker development processes than some of the more traditional Standards Development Organisations.
Interesting examples include:
A further set are the UK Urban Traffic Management and Control (UTMC) specifications. UTMC is well-known in the UK traffic management community, being initially developed by the forerunner to DfT. The UTMC specifications can be found at https://utmc.uk/
Compliance testing enables client Authorities and their supply chain to protect themselves, their infrastructure and assets, their customers and the general public at large.
Several approaches to ratifying compliance to standards, linked to procurement, can be undertaken. These include:
Where traditional equipment is being specified (such as Traffic Signal controllers, Detectors, VMS, Pedestrian crossing displays etc), a well-developed set of Procurement Standards, managed by TOPAS, exist to aid the Purchaser. These standards are derived from earlier “TR25XX” standards formally managed by the Highways Agency. TOPAS, which is an expert grouping of Government, Local Authority and Manufacture representatives, regularly review and update these in line with changing technical landscapes and demand from Local Authority users. TOPAS also operates a “Registration” scheme which enables Purchasers to easily confirm which Products comply with each standard in the TOPAS set, via the TOPAS website.
Many technical standards provide means to support a wide range of use cases or configurations that are commonly found. Therefore, standards regularly provide defined choices, optional elements and sometimes profiles. Some standards also support extensions. “Profiles” may be used to tailor use of the standard to a particular defined pattern of use (for example, a standard defining a common payload for, say, messaging between the infrastructure and vehicles may provide profiles tailored towards particular types of vehicles or different messaging use cases).
Within procurement, it can often be too limiting to simply state that a solution must be compliant with a defined standard or set of standards. Procurement specifications may need to go to a further level of detail by declaring support for required choices of optional elements, and/or profiles, or a procurement option to implement options or profiles at a later point of deployment.
The level of technical definition, described above, can be challenging within the constraints and available expertise of Authority resources. It may be appropriate to narrow down potential options to those required through a combination of other actions. These may include early market engagement and early engagement between authorities and suppliers to secure agreement on options and profiles to support desired use cases and related functionality. This can appear to add additional complexity around procurement but is essential. This is because legitimate but poorly defined uses of standardised solutions may provide profiles where the interoperability between different profiles cannot be guaranteed.
Many technical standards provide means to support a wide range of use-cases or configurations that are commonly found. Therefore, standards regularly provide defined choices, optional elements and sometimes profiles. Some standards also support extensions. “Profiles” may be used to tailor use of the standard to a particular defined pattern of use (for example, a standard defining a common payload for, say, messaging between the infrastructure and vehicles may provide profiles tailored towards particular types of vehicles or different messaging use-cases).
Within procurement, it can often be too limiting to simply state that a solution must be compliant with a defined standard or set of standards. Procurement specifications may need to go to a further level of detail by declaring support for required choices of optional elements, and/or profiles in one or more standards, or a procurement option to implement options or profiles at a later point of deployment.
The level of technical definition, described above, can be challenging within the constraints and available expertise of Authority resources. It may be appropriate to narrow down potential options to those required through a combination of other actions. These may include early market engagement and early engagement between authorities and suppliers to secure agreement on options and profiles to support desired use-cases and related functionality. This can appear to add additional complexity around procurement but is essential. This is because legitimate but poorly defined uses of standardised solutions may provide profiles where the interoperability between different profiles cannot be guaranteed.
It is important to recognise that any formal references to standards, for example in a procurement specification, should be date or version specific. Standards are subject to ongoing consensus-led peer review and revision processes – standards and versions do change over time. Thus, there needs to be a clear approach and understanding laid out in relation to procurement and of service or system supply with respect to how the Authority expect suppliers to maintain their offering. This closely relates to the approach to maintaining conformance and compliance with baseline standards.
Different strategies may be adopted, each with different advantages and disadvantages. For example, an approach of maintaining compliance to the latest version of any standard can employ periodic updating of technologies, data formats, interfaces, messaging protocols, security mechanisms, etc. For longer duration contract procurement, this is likely to introduce additional costs, to enable the supplier to upgrade systems and services to comply with a newer version of a standard. However, this approach benefits from adoption of the latest use of a standard (perhaps applying the latest design thinking. It gives the greatest basis to ensure interoperability of the Authority’s systems and services with other third-party systems and services over time. This also supports improved portability of solutions to alternative suppliers, as their solutions are likely to conform to the latest standards.
Alternatively, an approach can be adopted, which may have lower initial expenditure costs, to baseline services and solutions against a specific version of any standards. Although this reduces the burden of any up-versioning, it also introduces risk that the Authority’s systems and services may become incompatible with other similar solutions to which they is interfacing, or in shared common usage.
A result of the above is that a clear approach to what is called “configuration management” is recommended. “Configuration management” is a defined process that describes how upgrades to and replacement of existing systems and components are to be managed. Each supplier should be asked to define their “configuration management” practices as part of the procurement process.
There is no existing unified architectural model agreed and adopted for the deployment of smart streets related systems and services. Local needs and capabilities have, and will continue to, drive the adoption of different choices, landscapes of systems and services and underlying architectures to support them.
However, the need in some specific domains for greater levels of coherence or the availability of national complete data sets, has driven greater harmonisation and the use of standards. In general, such initiatives are linked to legislation. Two examples of this are:
In both cases, these services are strongly underpinned by defined services. More information is provided below.
However, other domains that interface with Smart Streets are not so strongly regulated in the UK, and the available standards that can be used may be more difficult to discover, identify and correctly deploy. Some helpful resources are given below.
The resources listed below do not create a complete picture and do not provide full coverage of relevant standards and specifications across smart streets. Authorities may wish to seek expert support.
There is no central resource or repository of standards relating to smart streets. Some domains provide clearer access to resources. Some key examples are given below:
Local transport authorities are required to maintain NaPTAN stop data and should enable operators to publish data to this service to fulfil the operator requirements.
Further information is available at https://www.bus-data.dft.gov.uk/ .
The DATEX II website (www.datex2.eu) provides guidance, downloadable data models and schema, and toolset support.
For more information see http://www.topasgroup.org.uk/.
Further information can be found at https://www.gov.uk/guidance/plan-and-manage-roadworks
Further information can be found at https://www.c-roads.eu/platform.html.
The following resources may be helpful in general in finding more information on relevant standards: