readi industry service...2020/06/12 · properties iec 61360 in addition, properties exsist in...
TRANSCRIPT
READI industry service
Demonstrating O&G digital transformation
Demo no.: 612th of June 2020
The duration of this session is 60 minutes.
Since this is a Teams Live event, your microphone is automatically muted.
Use the grey chat box to the right to post your questions during the session.
Notify us in the chat if you experience connection drop-outs or sound problems.
Please note that the session will be recorded.
Video of the demo will be available on our website readi-jip.org.
READI webinar - before we start
Welcome everyone
to this READI demonstration
of O&G digital transformation
Disclaimer
○ The purpose of these demos is to show status of the ongoing work in the READI JIP
○ This is not the end product, there will be several changes
○ The demo is made to be understandable for most people
○ To make it understandable for most people, we have simplified the cases we present
○ The final READI digital service will contain much more features, requirements and information
Content of this demo
1. Words from Ian Horrocks, professor at Oxford University
2. We have several standards for the same thing
3. How to reduce the number of requirements and make them more consistent by inheritance of requirements?
4. Demo time:
Connect terms and definitions from several standards
Requirements for an equipment package and inheritance of requirements
The contractor Aibel will demonstrate its use of READI
READI JIP scope – digital transformation of requirements
Digital requirements
READI changes and improves:
• Requirements – being digitally machine readable
• Work process – revised and more efficient work process
• Time and effort used to make, understand and use requirements
READI service
Operator Contractor/supplier
Digital requirements
Digital requirements
READI – in the frontier of digitalization
○ Some of the features READI develops are complex and complicated
○ To ensure success, we have a close co-operation with the department of Informatics at the University of Oslo, the Sirius centre
○ The department of Informatics at the University of Oslo have close co-operation with other universities
○ One is the University of Oxford
1. Words from Ian Horrocks
○ Ian Horrocks, professor of Computer Science at the University of Oxford
○ Visiting Professor in the Department of Informatics at the University of Oslo
○ Fellow of the Royal Society, a member of Academia Europaea, an ECCAI Fellow and a Fellow of the British Computer Society
○ Author of several standards, including W3C OWL 2 directsemantics standard (the most important standard for READI)
The Semantic Web
• The Web was “invented” by Tim Berners-Lee (amongst others)• The first web page went live on August 6, 1991
• In 2001 he set out an ambitious vision for a “semantic” web:
“… an extension of the current web in which information is given well-defined meaning”; in particular, is “meaningful to computers”
Semantic Technology Standards
Semantic Technology Standards
Semantic Technology Standards
2023
Semantic Technology Use Cases
Configuration
Risk & compliance
Data Integration
AI Q&A
Material Master Data Project
Engineering Domains: Piping, Structural, etc.
• Types• Geometry• Pressure classes• Fire classes• Explosion ratings• Materials• Certificates• Manufacturers• Revisions• +++
Cost EstimatesMaterial CatalogsInterchangeability
EfficiencyDigitalization
ReuseData Exchange
Master DataAutomation
?
RDFox• High performance knowledge graph and semantic reasoning engine
• Developed and formally validated at the University of Oxford• Now developed by Oxford Semantic Technologies
• Version 3: Incremental aggregation, named graphs, persistance, access controls and user console
http://www.oxfordsemantic.tech/request-eval
Configuration management at
Data consists of basic facts about components and their attributes and constraints.
Ontology/rules provide an appropriate language in which compatibility and configuration knowledge can be expressed.
RDFox computes all consequences of Data+ontology/rules in materialization (AKA reasoning) phase.
Query answering is then very fast (typically milliseconds).
Incremental reasoning means that changing data or ontology/rules is also very fast.
[?M, :compatibleWith, ?PS] :-:DCMotor[?M] ,:DCPowerSupply[?PS] ,[?PS, :provides, :DCVoltage] ,[?PS, :providedVoltage, ?pv] ,[?PS, :providedCurrent, ?pc] ,[?M, :requires, :DCVoltage] ,[?M, :requiredVoltage, ?rv] ,[?M, :requiredCurrent, ?rc] ,FILTER (?pv = ?rv && ?pc >= ?rc) .
Thank you for listening
I will try to answer questions in the chat
2. We have several standards for the same thing
o Most of our standards are originated from the «pen and paper time»
o Business functions and disciplines have therefore not been coordinated
o Therefore, we have several standards for the same thing
o This needs to be solved, and READI has a solution for this!
The READI solution to this
o READI uses the W3C OWL 2 direct semantics standard (internet standard)
o We use this to make a public global unique identifier (web link) for terms and definitions
o By referring to this global unique identifier (web link), everyone use thesame term and definition
o Example: Temperature , link
Unique global reference for a term with a definition
READI solution
○ For instrument properties READI uses IEC 61987, and for electricalproperties IEC 61360
○ In addition, properties exsist in NORSOK, CFIHOS, Mimosa and other
○ READI can connect properties between standards in an open and standardized way
○ This standard method is called SKOS mapping in W3C, the standards for internet
○ Then computers can support us in aligning standards
3. How to reduce the number of requirements and make them more consistent by inheritance of requirements?
○ In «pen and paper» or sentence based requirements, a requirement needsto be repeated several times
○ When requirements are made by algorithms, being machine readable, requirements can be inherited from a higher level to a lower level
○ Then two things happen:
• We don’t need to repeat requirements at each level
• We can check that all our requirements are consistent from facility level down to each component
Equipment package
○ An equipment package consists of several components
○ An equipment package is normally connected to one or several systems
○ In READI we will:
• Inherit systems requirements down to the equipment package
• Add additional requirements to the equipment package
• And as demonstrated before, we can automatically check that a product fulfillsour requirements
A few words about the Norwegian contractor Aibel
○ Aibel is a pioneer in making and using digital requirements
○ They have had the READI concept in operation for several years
○ The use and features Aibel have are very advanced and effective
○ It’s a privilige to welcome Aibel and Per Øyvind to this demonstration
3. Our live demo today
○ We have three use cases we will demonstrate today:
1. How to connect terms and definitions from several standards
2. Inheritance of requirements and requirements for an equipment package
3. The contractor Aibel will demonstrate its use of the READI concept
It’s demo time
Summary of the READI JIP demo today
1. Words from Ian Horrocks, professor at Oxford University
2. We can align standards by connecting them digitally
3. How to reduce the number of requirements by inheritance, make them more consistent and how we can use this for equipment packages?
4. Demo time:
Connect terms and definitions from several standards
Inheritance of requirements and requirements for an equipment package
The contractor Aibel have demonstrate its use of the READI concept
READI contact information
Senior digitalization project manager
Robert Skaar, Equinor
E-mail: [email protected]
Mobile: +47 488 91 667
http://www.readi-jip.org
Head of steering committee
Steinar Mollan, Equinor
E-mail: [email protected]
Mobile: +47 974 19 251
http://www.readi-jip.org
READI project manager
Erik Ostby, DNVGL
E-mail: [email protected]
Mobile: +47 906 74 106
http://www.readi-jip.org
Thank you for your attention, see you on the 26th of June