Jump to content

Recommended Posts

Ian Gordon
I've been drafting a Digital Twin Policy for HE and would appreciate any feedback. Some of it is quite HE-specific, but I'm hoping that the broader structure and themes is accessible to non-HE people. What do you think?
[Very very draft] Highways England Digital Twin Policy
 

Purpose of this document:

  1. Definition: To agree a working definition of Digital Twin for Highways England, and provide some context on the National Digital Twin programme.
  2. Principles: To establish a consistent and generally accepted set of principles for the creation and use of Digital Twins by Highways England and associated supply chain projects, and align these to the Information Principles described in our Information Vision & Strategy.
  3. Architecture: To describe the common data and technology underpinnings of Digital Twin development within Highways England, including infrastructure, integration, and interfaces, aligned with National Digital Twin programme's Information Management Framework.
  4. Capability: To highlight the skills we require as an organisation in order to be an informed client and custodian of Digital Twins.
  5. Ethics: To set guidelines around the ethical implications of using Digital Twins to manage the Strategic Road Network.
  6. Governance: To document how we will govern Digital Twins within Highways England as a collaborative body of practice, as well as how we will quantify and capture the benefits of investment in Digital Twins.

This document should be read as contributing to the realisation of Highways England's Information Vision and Strategy and abide by our Information Management System.

 
content?preferNoRedirect=true&prefer=ext
CDBB imagery showing the digital representation of physical assets.
 

Section 1: Definition and context

Our definition of a Digital Twin is as follows:

A Digital Twin is a digital representation of a physical thing (and its operation) that one can query.

This definition helps us to distinguish between the concept of a Digital Twin, and the more established practice of BIM. The key differences are:

  1. Digital Twins can and should be part of the construction phase, but the focus of their use is on the operation of existing physical assets (e.g. the 99%+ of assets that are not currently under construction). Within our organisation (and the wider industry), there is often a loss of data capability as projects move from construction to operations as operators have typically been unable to exploit BIM products. By designing our construction models as nascent Digital Twins we have the opportunity to define the data and logic required to operate an asset at the start of the lifecycle, and ensure that the models we create during construction have operational value.
  2. The emphasis on being able to query Digital Twins is important. A Digital Twin should not be a static representation of an asset, it should reflect the logic of that asset in operation. This means that Digital Twins need to expose not just the material properties of an asset (e.g. location, dimensions, materials, etc.) but also the business logic governing that asset (e.g. how we as the infrastructure owner can intervene on that asset to change how it performs). This allows Digital Twins to enable better organisational decision-making through simulation and 'what if' scenarios.
  3. In order to realise the two points above, the data schema underpinning Digital Twins is necessarily more complex, and more focused on relationships rather than properties. BIM data standards, such as COBie or Uniclass focus on the hierarchies of assets, and their properties (e.g. "span belongs to bridge and is made of steel"). Emergent Digital Twin data models (including our own Highways England Ontology) capture not just the properties of assets but how the relate to their wider environmental and operational context (e.g. "span is corroded by road salts, damaged by vehicle incursions, is maintained when the flange has 20%+ corrosion, and supports a flow of 50,000 vehicles per day travelling on the M25 (as well as a broadband internet cable) causing significant safety and KPI impact in the event of failure"). Creating these data models demands the creation and maintenance of a deep 'knowledge graph' of the organisation.
 
getpreview.ashx?resolution=4&guidSite=49
Imagery courtesy of the CDBB. They emphasise that new assets should be view as interventions on the wider existing system. In the UK, construction annually adds only circa 0.5% by value to infrastructure as a whole. The quality of the services delivered to the economy, environment and society is determined by the 99.5% of infrastructure that already exists. Construction of new assets is important but to make a significant difference to service quality, value, and outcomes for people the focus should be on the infrastructure that already exists. CDBB believe that viewing and operating our infrastructure as a system of systems will deliver better outcomes for citizens, the Information Management Framework will help enable improved secure, resilient data sharing across the built environment to make sure the better information gets in the right hands, at the right time, to make the better decision.
 

Where possible we seek to align with, and contribute to, the Centre for Built Britain's National Digital Twin programme. More information is available on the CDBB's website and we would also encourage staff to join the Digital Twin Hub. If you are new to the concepts behind the Digital Twin and the National Digital Twin programme, we would recommend reading their publication 'The approach to delivering a National Digital Twin for the United Kingdom'.

 
content?preferNoRedirect=true&prefer=ext
The NDT's Gemini Principles
 
 

Section 2: Principles

Digital Twins are ultimately an extension of data and information. As such, we believe that the principles set out in our Information Vision & Strategy are applicable to our development of Digital Twins (albeit with the need for a subject matter specific interpretation).

 

ID Information Vision & Strategy principles Digital Twin interpretation Relevant Gemini principle(s)
1 We will use information as best we can, even if it's not perfect.

"We will use Digital Twins as best we can, even if it's not perfect."

Our digital infrastructure is a work in progress. As such, we will design and develop a shared set of principles, architecture, governance, and capability that allows us to incrementally develop Digital Twins over the coming investment cycles. This means building upon and evolving our existing in-house digital infrastructure, avoiding creating undue reliance on proprietary solutions, and carefully managing the benefits case associated with investment.

Public good

Value creation

2 We will create the trust people have in our information by assuring its fitness for purpose.

"We will create trust in our Digital Twins by assuring their fitness for purpose."

We will ensure that the data that informs (or is presented in) our Digital Twins is subject to our Information Management System. We will assess the condition of data and its fitness-for-purpose so that health-warnings/uncertainties can be applied to the outputs of our Digital Twins (where necessary), and identify remediation activities where necessary.

Quality
3 Information can affect people's lives and we will use it transparently and ethically.

"Digital Twins can affect people's lives, and we will use them transparently and ethically."

As a public body, we shouldn't use Digital Twins in any manner that we would not be comfortable being public knowledge. Where possible we should seek to openly publish our approach to Digital Twins, including this policy document. This demands a detailed consideration of the ethics of our use of Digital Twins, as well as their potential for bias, which is covered later in this document.

Public good

Openness

4 We need to understand how the information we collect is used by others to make sure it is good enough for everyone.

"We need to understand how the outputs of our Digital Twins are used by others, to ensure that they are fit for purpose."

We understand that Digital Twins are only as good as the data and logic that go into them. Where staff or organisations are using Digital Twins to support decision making then we must be aware of the sensitivity of these decisions. We must then confirm that the data and logic used by the Digital Twin can provide sufficient accuracy to safely inform those decisions.

Quality
5 We must continually earn the right to look after our customers data.

"Our Digital Twins should not  directly or indirectly provide information on individuals or small groups of people."

The movement of our customers on the road network, and potentially related networks such as rail, will likely be a key data input to Digital Twins. However, clear limitations and governance must be placed upon how customer data is used within Digital Twins, including aggregation, anonymisation, and clear rules to avoid 'toxic combinations'.

Security
6 Information is a valuable resource that will be kept safe and secure from accidents and attacks.

"Our Digital Twins must not materially increase our risk of data breach or loss of customer data." 

Digital Twins require substantial quantities of information in order to work effectively. Any centralised storage of information on this scale will increase the risk of data loss, and whilst this risk can never be fully mitigated, we must take steps to ensure that we are securing our data storage infrastructure in accordance with best practice.

Security
7 Looking after information has a cost we should understand and account for.

"We will be aware of the on-going cost of maintaining our Digital Twins."

As per the previous point, even using public cloud resources there will be a substantial on-going cost for the storage and computation (not to mentioned resource) associated with running our Digital Twins. In addition, there is always an opportunity cost associated with expenditure, and we should seek to ensure that we are delivering a return on taxpayer's funding.

Curation
8 We all have a responsibility to look after our information so that it is fit for purpose.

"We will build our Digital Twins with clear data and logic ownership and stewardship responsibilities."

The component parts of the Digital Twin, including data and logic (algorithms) must have clearly defined owners, lineage, and steward roles to ensure that they remain fit-for-purpose.

Quality

Curation

9 Decisions made with information create better outcomes for our customers, stakeholders and ourselves.

"We will tie our use of Digital Twins to clearly defined outcomes for our customers, stakeholders and ourselves."

Digital Twins cannot simply be 'shiny things'. As part of the Governance described in this policy we will be clear on the benefits case associated with our investment in Digital Twins, and the outcomes that we are seeking to deliver.

Insight
10 The value of information is only realised when it's used to help make decisions.

"The value of Digital Twins is only realised when they are used to help make decisions."

This is probably the most important principle. We will use Digital Twins to affect a positive (and cost-effective) change on how we build, operate, and maintain our network. All development of Digital Twins must be able to demonstrate how it will contribute to this goal.

Insight
 

Section 3: Architecture

The use of Digital Twins will likely vary substantially across our business. Different teams will work at different stages of the asset lifecycle (e.g. plan, design, build, operate/maintain, dispose), and consequently their teams will have different skillsets, ways of working, and levels of supplier involvement. This does not, however, mean that our use of Digital Twins across the business must be disconnected and siloed. If we end up with a number of standalone Digital Twins then we are likely to miss the greater benefit of understand how our infrastructure behaves throughout the lifecycle. We believe in a 'federated' model, one where parts of the business can design and develop Digital Twins to meet there use cases, but which ensures adherence to common standards described in this policy. 

The diagram below describes, at exceptionally high level, the common 'schema' and 'data' layers that we should seek to create to support our federated Digital Twins in the application layer. Key to this architecture is the use of open platforms wherever possible, whether those are open data standards, open source tools, or solutions shared with other Digital Twin owners. We want to avoid Digital Twins within Highways England becoming entirely dependent upon proprietary solutions and walled gardens, and we believe that there are lessons to be learned from the successes and failures of BIM in this respect. Ultimately we want to own our own destiny in this space, and build capability within Highways England.

 
content?preferNoRedirect=true&prefer=ext
Indicative components of the Highways England federated Digital Twin
Image web part, showing Indicative components of the Highways England federated Digital Twin.
 

WThis architecture will build upon existing and proposed corporate services that will be accessible to the organisation and its supply chain, as per the table below.

Component Current Position End State Position
Schema (structure) Our Corporate Ontology provides a logical map of our organisation from a data perspective.
Our Data Modelling standards provide guidance as to what artefacts should be created to document new systems (including Digital Twins).

We will continue to develop our Corporate Ontology as we create Digital Twins, with a focus on increasing boths its completeness, and the ease with which Highways England staff can view, edit, and use the Ontology to keep it up-to-date and to inform the design of Digital Twins.

We will work to align our Corporate Ontology with data standards specified under the NDT's Information Management Framework and adopt all or part of their Foundational Data Model once this becomes available.

Data Storage (inc. Graph) Our Azure-based common data environment, Data-as-a-Service (DaaS), provides a corporate approach to storing and sharing information within Highways England. We will expand DaaS to incorporate a graph database built to reflect the schema set out in our Corporate Ontology, and populated with datasets relevant to our Digital Twins.
Data Exchange (inc. API) Our intention is to extend the functionality of DaaS to include for an 'HE API', as well as Master Data Management functionality to deliver a 'single source of truth' of data drawn from systems of record across the organisation.  Highways England will publish data externally through a common set of documented open data feeds managed as a single holistic service (e.g. the 'HE API'). These data feeds will reflect the underlying structure of data specified in our Corporate Ontology and data models.
IoT / Sensors Our intention is to extend the functionality of DaaS to handle real time 'event' data. This will allow DaaS to serve information from sensors into Digital Twins. Though in practice is it also possible that sensors will report directly into Digital Twins and then subsequently share that data with DaaS for wider distribution.

The risk we face with the adoption of IoT is that, to date at least, it has been extremely piecemeal. This is in part because, in many cases, the marginal cost of sensors does not yet make it cost-effective to deploy them ubiquitously. Often our IoT data doesn't even make it on to the HE IT estate.

We are going to come to a point where centralised management of data from IoT becomes substantially more important for us an organisation in order to avoid different departments and Digital Twins needing to make duplicate investments. Some evolution of our common data environment will need to accommodate this change.

Our corporate approach to data modelling and creating a common data environment underpins our federated approach to Digital Twins within Highways England. More information on our corporate solution, and how it is available to build digital solutions within Highways England, is available on our Data-as-a-Service SharePoint page.

We will work to understand the division of responsibility, and necessary interconnections, between Data-as-a-Service and other Digital Twin and data management solutions including HEADDS and BIF.

 
content?preferNoRedirect=true&prefer=ext
Diagrammatic representation of current data collation within Highways England
Image web part, showing Diagrammatic representation of current data collation within Highways England.
 

 

Section 4: Capability

The capability that our Digital Twins provide us as an organisation should stem logically from our definition of a Digital Twin as "a digital representation of a physical thing (and its operation) that one can query." We should look for our Digital Twins to provide us with capabilities beyond what can be realised by existing BIM systems and other digital technologies.

There are (at least) two dimensions to the capability that Digital Twins will provide us, breadth (e.g. the proportion of our portfolio of assets that is represented by a Digital Twin), and depth (e.g. the range of queries that it is possible for us to conduct using those Digital Twins). The question of breadth is a relatively simple one of scale, which hopefully deploying our Digital Twins cost-effectively on scalable public cloud solutions will help realise. The question of depth is much more interesting as it relates to the functionality of the Digital Twins we build, and the use cases that we want to realise.

Our aim is for Digital Twins to provide us with a range of functionality, including:

  • The ability to run 'what if' scenarios to understand the consequences of changes to how we manage our network. These scenarios should be able to consider a range of parameters including the performance of assets, the configuration of the network, maintenance policy, traffic management, and the impact of external factors including levels of customer demand, weather, incidents, and disruption to other transport and utility services.
  • Exchange of information with other organisations, including other road operators and stakeholders (e.g. Local authorities, Transport Scotland, Transport for Wales, emergency services), transport operations (e.g. Network Rail, TfL, HS2, HAL, MAG) and utility operators (e.g. UKPN, National Grid, water companies).
  • Highlighting inter-dependencies with other organisations, we know that our infrastructure is crucial to other organisations working effectively, whether it's the transport of crucial supplies, providing a route for maintenance teams to get to asset failures on other networks, or in some cases literally supporting 3rd party cables and pipes with our structures. Our Digital Twin will understand these inter-dependencies and highlight potential choke-points.
  • Mapping of assets to outcomes, in other words how do individual assets on our network contribute (or not) to the overall performance of the network itself. We have all seen instances where the failure of individual, relatively insignificant assets can result in substantial disruption to how the network as a whole operates. As an organisation we should be aware of these potential choke-points, not only in terms of how they effect our business, but also in terms of how they impact our stakeholder's goals.
  • Mapping of organisational workflows to outcomes, in other words how do our organisation's decision-making processes and operating model influence and potentially change the real world outcomes.
  • Presenting a time-series view of the organisation, for all of the functionality listed above we should be able to see change over time, both looking back into the past, and projecting into the future. 

Whilst we continue to develop our Digital Twins to deliver this functionality we need to be mindful of the training and staff capabilities that we need to build within the business, who should be accountable within the business for owning them, and what we should be looking to procure through our supply chain.

Key roles will likely include:

  • Data owner;
  • Data steward;
  • Product owner;
  • Platform developer;
  • Software developer;
  • UI/UX developer;
  • Technical project manager;
  • Business analyst;
  • Data analyst;
  • Data scientist;
  • Data architecture;
  • Technical SME;
  • Benefits manager.

Consequently, any development of a Digital Twin within Highways England must include for a consideration of the resources required to maintain, administer, and continuously improve the Digital Twin throughout its lifecycle. This will need to consider and engage on the appropriate division of responsibility between HE Directorates, ITD, and the supply chain.

 

 

Section 5: Ethics

Digital Twins of our infrastructure are a potentially transformative technology that will change how we interact with, and manage, our built environment. Consequently, it is worth our considering the ethics of when and how we develop Digital Twins so as to control for unintended or biased outcomes. In many ways, the conversation around ethics of Digital Twins is an extension of the conversation on the ethics of Artificial Intelligence in general. As such, it makes sense to take guidance from the wider body of literature on this topic.

A good reference point is The Alan Turing Institute's 'Understanding artificial intelligence ethics and safety' This states that:

"In order to manage [the impacts of AI] responsibly and to direct the development of AI systems toward optimal public benefit, you will have to make considerations of AI ethics and safety a first priority. This will involve integrating considerations of the social and ethical implications of the design and us of AI systems into every stage of the delivery of your AI project."

The Institute's report lays out the following potential harms of AI, all of which extend to Digital Twins, and many of which you will have started to see instances of emerge in the real world:

  • Bias and discrimination;
  • Denial of individual autonomy, recourse, and rights - particularly pertinent to Digital Twins of infrastructure that need to account not just for the predominance of users, but also for minority and disadvantaged user groups.
  • Non-transparent, unexplainable, or unjustifiable outcomes - when we are spending public money, we need to be able to explain the process that determine our investment decisions.
  • Invasions of privacy - our principles earlier in this document touch upon the risk violating data protection legislation.
  • Isolation and disintegration of social connection;
  • Unreliable, unsafe, or poor-quality outcomes - again, particularly relevant when dealing with physical infrastructure.

The report then goes on to lay out what steps we should seek to take in order to ensure that we are building an ethical platform. Rather than paraphrase the Institute's report into its entirety in this policy, the recommendation is that we use the guidelines set out in this report as the ethical framework that we apply to the development to Digital Twins.

 
content?preferNoRedirect=true&prefer=ext
FAST Track Principles from the Turing Institute
Image web part
 

Section 6: Governance 

Collectively, the definition, principles, architecture, ethics, and governance should allow different parts of Highways England to conduct Digital Twin development whilst minimising the risk of inconsistent, redundant, unaligned, or unethical development.

The Digital Twin working group exists as a cross-directorate informal meeting to exchange knowledge on the development and application of Digital Twins within and beyond Highways England, and to see to develop common standards.

Our Governance should seek to ensure that:

  1. This policy is visible within the business;
  2. Parts of the business are not developing or engaging in Digital Twin work in ignorance of this wider coordination effort;
  3. The members of the Digital Twin working group are able to support digital transformation as it occurs across the business, including Digital by Default, Operational Excellence, Asset Management Transformation, Digital Roads, Digital for Customers, etc;
  4. Whilst the Digital Twin is not formally a subsidiary of any other body, we should look to report back into the relevant governance of the programmes listed above, as well as ITD's DDAT board.

Broadly, the governance should follow:

  • Digital Twin working group: meeting every two months with representatives from MP, Ops, SES, ITD, and other interested Directorates and suppliers. Responsible for drafting and maintaining this Digital Twin policy and other guidance documents.
  • Representation at Digital by Default, OE 2025, AM Transformation, Digital Roads, Digital for Customers, DDAT, via one or more named members of the Digital Twin working group.

This is intended as soft governance where the membership of the Digital Twin working group, and the guidance documents that it originates, can influence and report on the development of digital capabilities across the business.

 

Edited by Ian Gordon
Adding tags.
  • Like 3
Link to post
Share on other sites

oh man this is big, I've skimmed it, but I'll come back to it in earnest soon @Ian Gordon.

From my first pass the tone is right and it doesn't read like policy statements of old that sought to write in stone eternal truths and irrefutable facts with thou shalts and orders from on high, but ultimately were trying to nail jelly to the wall. This reads like something that clearly sets out the philosophy, the context and the direction of travel for digital twins in HE that understands the fluid nature of the situation and is ready to adapt to that.

  • Like 2
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Top
×
×
  • Create New...