Using Standards

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.

Smart streets, involve the delivery of data & technology driven, or ‘smart’ services for streets and highways. This presents a diverse, complex, geographically sensitive, and evolving landscape for standards. Often services and systems may be deployed using different technologies and deployment approaches.

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:

  • security,
  • authentication,
  • the storage and retrieval of data,
  • system response times,
  • requirements concerning adding new users or removing old ones,
  • access rights and permissions and user roles, etc.
  • the need for maintenance

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:

  • are built on a basis of consensus (although the nature of that consensus may be different),
  • to be freely and reasonably available (though not necessarily free to purchase), and
  • should declare any rights, patents or restrictions on use.

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:

  • facilitating trade, particularly in reducing technical barriers and artificial obstacles to national and international trade,
  • providing a framework for achieving economies, efficiencies and interoperability,
  • enhancing consumer protection and confidence,
  • where appropriate, supporting public policy objectives, and
  • where appropriate, offering effective alternatives to regulation.

For an Authority, the use of and reference to a standard supporting Smart Streets offers the following benefits:

  • Services or systems supplied in conformance with a standard should be replicable by multiple suppliers and therefore reduce the risk of vendor lock-in.
  • Support for ease of use by end users.
  • Interfacing and inter-operation between systems and services operating in a standardised manner should have greater predictability, reducing the risk of interoperability issues.
  • For some standards, agreed testing protocols and processes are defined.
  • Standardised solutions often have wider industry toolset support and shared collaboration concerning guidance, best practice, troubleshooting and issues, i.e. benefitting from a wider community of users.

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.

 

Legislative context – Procurement

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 Sector: Directive 2014/24/EU of the European Parliament and of the Council of 26 February 2014 on public procurement and repealing Directive 2004/18/EC
  • Concessions: Directive 2014/23/EU of the European Parliament and of the Council of 26 February 2014 on the award of concession contracts
  • Utilities: Directive 2014/25/EU of the European Parliament and of the Council of 26 February 2014 on procurement by entities operating in the water, energy, transport and postal services sectors and repealing Directive 2004/17/EC

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.

 

Legislative context – Smart streets

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:

  • the transportrequired to meet the needs of persons living or working in the Authority’s area, or visiting or travelling through that area, and
  • the transportrequired for the transportation of freight; and
  • includesfacilities and services for pedestrians.

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:

  • Traffic movement using the following objectives:
    • securing the expeditious movement of traffic on the Authority’s road network and
    • facilitating the expeditious movement of traffic on road networks for which another Authority is the traffic authority.
  • Traffic Management Act 2004 Part 6: a framework for the enforcement of parking, bus lanes and certain moving traffic matters
    • Moving Traffic Offences Section 78: notification, adjudication and enforcement

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.

Policy landscape

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:

  • well documented publicly available and free to use to provide fair access
  • supported by the market to demonstrate independence of platforms applications and vendors released for use with a royalty free licence which is irrevocable unless there is a breach of conditions
  • Compatible with both open source and proprietary licence solutions

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 business standards

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 ISO 9000 series of standards for Quality Management Systems,
  • the ISO 27000 series of Standards for Information Technology security, and
  • the ISO 14000 series of standards for Environmental Management.
  • Other standards e.g. the Payment Card Industry Data Security Standard – needed if you are handling cardholder data.

 

National highway and street standards (UK)

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.

Well recognised formal Open Standards

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:

  • Unified Modelling Language (UML) for data modelling
  • encoding standards like JSON and XML,
  • encryption and security techniques.

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.

Industry Standards

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:

  • The Mobility Data Specification (MDS) which provides a specification for the coding and exchange of mobility related data. MDS in particular focuses on more novel mobility services such as ride-hail (such as Uber and Lyft), but also for other mobility means, such as e-Scooters.  MDS is curated and developed by the Open Mobility Foundation (OMF), and is deployed in a number of cities in north America, and early adopters in Europe. For more information on OMF and MDS see https://www.openmobilityfoundation.org/.
  • Similarly, there are competing industry standards and specifications emerging in relation to data exchange relating to electric vehicle charging points. Perhaps the most widely deployed in Europe is the Open Charge Point Interchange (OCPI) protocol which is maintained by the EVRoaming Foundation. For more information on OCPI and the EVRoaming Foundation see https://evroaming.org/.

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

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:

  • self-certification by supplier organisations
  • independent third-party certification – For TOPAS Registered Products a process of independent assessment by a Technical Assessor is always required.
  • agreement, adoption and performance of test procedures, these may include well known concepts such as factory acceptance testing and site acceptance testing
  • peer or expert review.

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.

Essentials, options and profiles

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.

Essentials, options and profiles

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.

Versioning and configuration management

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:

  • The Bus Open Data Service which is deployed as a centralised service and used to fulfil the requirements specified in The Bus Services Act 2017.
  • The Street Manager service is deployed as a centralised service for the registration and sharing of other information relating to street and road works.

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.

Resources for standards – MfSS domain

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:

  • Bus Open Data Service (BODS). The DfT led initiative, supporting The Bus Services Act 2017. The Bus Services Act 2017 requires operators of local bus services in England to publish data to the Bus Open Data Service. There are three types of data that operators must published in certain data formats: timetables, bus location and fares.

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/ .

  • Standards for Traffic Management Data Exchange (DATEX II).  DATEX II is a long-standing European initiative defining the European Standards for the terminology, encoding and exchange of several forms of traffic management data.

 

The DATEX II website (www.datex2.eu) provides guidance, downloadable data models and schema, and toolset support.

  • Urban Traffic Management and Control (UTMC). UTMC provides UK specifications for the deployment of interoperable traffic management equipment and traffic management control systems.  The UTMC specifications and guidance can be found at https://utmc.uk/.
  • Traffic Open Products and Specifications (TOPAS). TOPAS is the managed resource for new product registrations for traffic control and associated equipment.  TOPAS manages the publication of technical specifications for traffic control equipment and offers means for customers to verify compliance with these through its product registration system.

For more information see http://www.topasgroup.org.uk/.

  • Street Manager. The DfT centrally hosted ‘Street Manager’ service must be used to:
  • apply for street and road work permits
  • assess permits
  • record inspections
  • add reinstatements (after work has been completed)

Further information can be found at https://www.gov.uk/guidance/plan-and-manage-roadworks

  • Connected Vehicles (C-Roads). C-Roads The C-Roads Platform is a cooperation of European Union Member States and road operators working on the deployment of harmonised and interoperable connected vehicles (C-ITS) services in Europe. DfT and National Highways participate on behalf of the UK.

Further information can be found at https://www.c-roads.eu/platform.html.

 

General resources on standards for smart streets

The following resources may be helpful in general in finding more information on relevant standards:

  • The mobilityits.eu website is an experimental resource being developed at a European level by a European Union funded project team, developing an accessible resource two formally recognised standards within different sectors of ITS. This is a European resource and therefore does not list UK standards. The site is still under development.
  • The DfT’s “finding transport data” hub is an emerging resource that may provide useful information on sources of data under format available within the transport main in the UK
  • Formal standards development bodies also provide listings available standards within their catalogues, a majority of which are available on a paid basis, these include:

 

Disclaimer: The Manual for Smart Streets is currently DRAFT content under development. It has not yet been released to the public and has only been shared with selected stakeholders for the purpose of review.

All content should not be used for any purpose other than to review the current state of this draft content.

*** Proposed final text for this footer***
The Manual for Smart Streets is a living document that will continue to develop through engagement. Please do contact us using the link below if you have any questions, feedback, or content to contribute.

Contact Us