Digitized requirements for automated verification

(1)

Digitized requirements for automated verification

A real-world case study

Kai Arne Schröder Myklebust

Master of Informatics:

Programming and System Architecture 60 credits

Department of Informatics

The Faculty of Mathematics and Natural Sciences UNIVERSITY OF OSLO

January 2022

(2)

II

(3)

III

Digitized requirements for automated

verification

(4)

IV

Digitized requirements for automated verification: A real world case study Kai Arne Schröder Myklebust

http://www.duo.uio.no/

Trykk: Reprosentralen, Universitetet i Oslo

(5)

V

Summary

Digital requirements are essential for automated verification to work effectively. This case study will look at ways to digitize requirements in a project from the Oil & Gas sector, more specifically from an existing but anonymized oil platform. Making automated verification possible I will focus on how to build a system that can accommodate requirements in a digitized format.

Through my thesis I will try to answer two main questions set out at the beginning of the case study. “What can digital requirements help us with?” and “How shall digital requirements and their corresponding digital product representations be created to become valuable?”

I will through this work introduce new concepts such as functional system blocks and model blocks. In addition, I will present the asset information modelling framework developed in collaboration with the READI JIP work group. Functional system blocks and model blocks are one part of this framework. These blocks originate from the need of a more structured approach on how documentation of products is created. I used the ISO 81346 standard as a foundation on how to structure objects and information and build the blocks on top of it.

The result of this work looks promising as of now. I developed new concepts and they need to be implemented in a real-world system. This system should use ontologies that can verify requirements automatically instead of manually. Ontologies are digital concepts used to model an object. My model blocks are created to be compatible with ontologies so that they can be verified automatically.

(6)

VI

(7)

VII

Foreword

This thesis is the finalisation of my master’s degree in informatics with specialization in Programming and System Architecture at the Department of Informatics, University of Oslo.

The scope of this thesis has been created through the collaboration between Professor Arild Waaler and me. Arild introduced me to the IMF workgroup and through the collaboration with them the content of this thesis has been developed.

First, I would like to thank my supervisor Professor Arild Waaler from the SIRIUS group at the University of Oslo, Department of Informatics for his advice, insights, guidance, and support through my thesis. And especially his understanding and encouragement in difficult times.

I would like to thank everyone from SIRIUS, READI, Equinor and Aibel in the IMF workgroup for the opportunity to collaborate with them and the possibility to develop new and cutting-edge technologies. You all have been a great inspiration for me. I appreciate our discussions, your inputs, and the guidance you gave me.

I would also like to thank Daniel, Martin, and Magnus for answering all my questions. Your good and valuable feedback throughout my work on this thesis has been of great help and inspiration.

(8)

VIII

(9)

IX

Important terms

Term Description Explanation

Asset Model Specification

Specification of how aspect models are interconnected

“An Asset Model Specification is comprised of a set of aspect models, a set of inter-aspect relations, and a set of connected to relations.” (Fjøsna & Waaler, 2021, p. 37)

Aspect Specified way of viewing an object (International Electrotechnical

Commision (IEC) 81346, 2009, p. 12)

Comes from ISO 81346 and is used to describe the product, function, and location aspect of an object. Used in this thesis to divide an object into parts often developed by different people.

Digital Twin Virtual representation of an asset A real-time digital view of a physical object in a virtual representation. The findings from this thesis should eventually facilitate a digital twin.

Digitalizing Making the information process digital My results will be a part of making the process of requirements and products digital.

Digitizing Making the information format digital My main focus has been on making it possible for requirements to even be in a digital format.

(12)

2

ETO Engineer to order Many Oil & Gas companies are

engineer-to-order firms, this means that they for each new oil platform that gets built engineer it from scratch based on the order they get from the operator.

IMF Information modelling framework Also referred to as: “Asset information modelling framework”

A framework for structuring asset information with principles developed in the time I worked together with READI JIP.

IMF tree The tree from an Asset Model Specification created by the IMF

I use the term IMF tree to relate to the trees from an Asset Model Specification. Mainly used in the chapter about merging Asset Model Specifications.

Industry 4.0 The fourth industrial revolution Industry 4.0 stands for the fourth industrial revolution where a new level of control over the entire value chain of the life cycle of products is important.

Industry 4.0 and this thesis can be compared because of the focus on digitalizing the life cycle of products.

ISO 81346 ISO standard that specifies principles for structuring objects including their associated information.

Used in my thesis to create structure for all objects on an oil platform. This structure will

(13)

3

make digitizing requirements possible.

Model blocks Reusable individual fragments of information

“A concept where a fragment of an asset information model is encapsulated such that it can be reused in other asset information models” (Fjøsna & Waaler, 2021, p. 29) I have used model blocks to make requirements reusable and easier to insert into new systems.

O&G Short form for Oil and Gas Both Oil and Gas use very many of the same principles so often shortened to Oil & Gas or O&G Object One part of an oil platform or more

generally any part of a system. “Entity treated in a process of development, implementation, usage and disposal”

(International Electrotechnical

Commision (IEC) 81346, 2009, p. 12)

Important term from ISO 81346, used often in this thesis and is used to describe an entity (part of an oil platform) through its whole lifecycle

Ontology The concepts used to model an object Used to model an object or a part of the object and showing the connections between the types of the object and

constraints (Fjøsna & Waaler, 2021, p. 6 / Important terms)

(14)

4

OTTR Reasonable Ontology Templates A tool for representing and instantiating ontology modelling patterns.

OWL Web Ontology language A standard way for modelling an

ontology

RDF Resource Description Framework Standard model for data interchange on the Web (W3, 2021)

RDS Reference Designation System From ISO 81346. “Identifier of a specific object formed with respect to the system of which the object is a constituent, based on one or more aspects of that system” (International

Electrotechnical Commision (IEC) 81346, 2009, p. 12) READI JIP Requirement Asset Digital lifecycle

Information Joint Industry Project

Project group that developed IMF. I have worked in

collaboration with them for this thesis.

Requirements How objects are supposed to perform, behave or what they need to withstand.

Requirements are critical components in the industry, describing qualities that a product or a service needs to have.

In my case study, I looked at how to digitize the requirements by looking at digitizing the products that have requirements.

By doing this I could make connections between products possible and allow requirements

(15)

5

to be verified across the whole system.

SCD Scope, Condition, Demand A way to structure requirements.

What scope has it, are there any conditions attached to this requirement, and what is the demand of the requirement.

Works great for ontologies, because its three properties can easily be incorporated into triples.

Semantic technologies

Help to derive meaning from information and making machines understand data

“Semantic technology is a set of methods and tools that provide advanced means for categorizing and processing data, as well as for discovering relationships within varied data sets.”

(Techtarget, 2021) SIRIUS Norwegian Centre for Research-driven

Innovation that addresses the problems of scalable data access in the oil & gas industry

Research group of Arild Waaler located at the University of Oslo. I got the possibility to do this thesis as part of this group.

System “A regularly interacting or

independent group of items forming a unified whole” (Merriam-Webster, 2021)

“A technical system is a group of components working together for a

System in my thesis is mainly used to define a setup where all digitized documents are

interacting and connected to each other.

(16)

6

specific purpose” (International Electrotechnical Commision (IEC) 81346, 2009, p. 15)

I have also used the word system in the context of a computer system or more precisely a program running on a computer modifying the digitized

documents.

Verifying Making sure that something is correct.

Verification is the act of evaluating whether a product complies with requirements.

In my case it is used to make sure that the products comply with the requirements, mainly by checking them against properties from that product and requirements and properties from other products.

(17)

7

1 Introduction

A major trend in all industries is digitization and digitalization. “Digitization is the process of changing from analogue to digital form, also known as digital enablement” (Gartner, 2021) and “Digitalization is the use of digital technologies to change a business model and provide new revenue and value-producing opportunities” (Gartner, 2021). “The digitalization of all industries has increased steadily in the past years” (Accenture, 2021). Cost-cutting and efficiency are the main drivers in this change. The covid-19 pandemic situation has

accelerated the process in the last two years (McKinsey & Company, 2020). Many industries have used the last years to digitalize parts of their business. Both the energy and

manufacturing sector still have high potential (Triare, 2021).

Oil and Gas operators and suppliers are still very analogue in their way of working. Their focus has traditionally been on “time to first oil”, because of high oil prices and large economic growth (OG21, 2015). This has resulted in the Oil and Gas industry being behind on digitization and digitalization.

My main starting point comes from the fact that the Oil & Gas industry is still working document centric. The problem with such an approach is that requirements are stored in documents mainly used by human beings and therefor are hard to implement in computer systems. When human beings manually go through documents this is time consuming and error prone.

1.1 My contribution

The starting point for my thesis was a discussion in the IMF working group in the READI Joint Industry Project. This was a group that was interested in digital requirements and how digital requirements could be beneficial in the oil and gas industry. The group consisted mainly of participants from industry, motivated by the aim in the industry to work more efficient and cheaper.

In the beginning this problem seemed almost impossible to comprehend and get a firm grip on and the discussion progressed over quite vague ideas and abstract concepts. In this work I looked at what the industry is doing with requirements. During the process of this thesis the understanding of the problem has matured through intensive discussions with IMF partners. It

(18)

8

has been a path of exploring, understanding and most importantly rejection where needed. In this process I did a literature review on ETO firms to get a better understanding of the struggles that the Oil & Gas industry is facing in producing new systems and reuse of solutions that have been proposed in the past.

My contribution with this thesis has been to create a structure from all our discussions. I have summarized our discussions in an original way. I have in particular introduced the concepts of functional system blocks and model blocks. The value of this thesis lies as much in the path to this as in the end result. The blocks might seem easy and uncomplicated. This is a good thing because we have gone from a difficult problem to elements of a simple solution, where the blocks will help the industry better represent their products and break out of the ETO principles.

1.2 My work processes

My master thesis is a case study based on a realistic case from the Oil and Gas industry as part of the IMF project in the READI JIP. This case is complex, complicated, multi-

disciplinary and has changed multiple times since I started. It is important to do this work to propose better solutions for handling big projects and especially their requirements.

For this case study I have been working together with the project group READI JIP (Requirement Assed Digital lifecycle Information, Joint Industry Project). This is a joint industry project between Norwegian oil companies. Owners, operators, contractors, and suppliers are all included in this JIP. In addition, the University of Oslo with the Sirius division, and firms as Aibel, Aker Solutions, DNV and TechnipFMC are involved in the READI JIP and have contributed to my work. One part of the READI JIP is to create the IMF, asset information modelling framework. IMF wants to provide “guidelines for structuring an asset information model as a basis for scalable implementations throughout the lifecycle of an asset from early design to operation” (Fjøsna & Waaler, 2021, p. 1). IMF is creating a

framework for the complete lifecycle of an asset, and I have in collaboration with them looked at the part of digitizing requirements. In this process I have created the concepts of functional system blocks and model blocks.

(19)

9 To start off, I will in chapter 2 define and present my research objective, two research

questions and go into depth on my research method.

In chapter 3 I will introduce fundamentals like ISO 81346 – “Industrial systems, installations and equipment and industrial products — Structuring principles and reference designations”, SCD (Scope, Condition, Demand requirements format), Semantic Technologies and

Ontologies. The ISO 81346 is the basis for how the functional system blocks and model blocks are structured and creates an international naming convention through their reference designations. The SCD requirements format makes it possible for the requirements in the model blocks to be represented in ontologies. By having a way of inserting the requirements in each model block the requirements can indirectly be represented in an ontology.

Then, in chapter 4, I will look at what engineer-to-order (ETO) is and what part of the development of new oil platforms are part of ETO. To accomplish this, I will do a literature review where I compare two articles about ETO firms. This will be an important introduction to the rest of the thesis, because Oil & Gas companies are often ETO oriented and use a lot of time to engineer new products.

In chapter 5 I will introduce the asset information modelling framework (IMF). A very important framework because my model blocks are a part of it and IMF needs my blocks to function. The model blocks give structure to the framework, by representing products and requirements digitally.

Chapter 4 and 5 shows the complexity through ETO and IMF and are important to both understand what the blocks shall solve and how they are created. They paved the way for the creation of two new concepts of blocks.

In chapter 6, I will look at how to handle the complexity of ETO and IMF with the help of standardized system blocks. Functional system blocks and model blocks are my main

(20)

10

contribution to the IMF work and the most important part of this thesis. These blocks have been created based on ISO 81346 and shall be used to store requirements in a better way.

In chapter 7, IMF tree merging, I will be looking at how to merge Asset Model Specification trees created by the asset information modelling framework. The challenge in ETO firms is that there are multiple companies working together. Merging all their work can create a high degree of complexity. By using the IMF tree with the block concepts, I expect merging to become more standardized and therefore less complex. In addition, it should become faster, easier, and hopefully safer for the product that gets built.

In chapter 8, Future ontology work, I will be talking about technologies that can represent the model blocks and their requirements. I will present different possibilities to use ontologies for my case to allow for automated verification. Having the right technologies is especially important for the possibility to scale this up outside of small examples. In the real world the data sets will be much larger. The ontologies should make it possible to move the

requirements into the digital world and make them manageable for the huge amount of data.

In chapter 9, I will go through limitations and some recommendations for the future before I in chapter 10 will conclude by tying together the findings from my thesis.

(21)

11

2 Research

Objective

The goal of my thesis is to create a foundation with the help of digitized requirements that ultimately can be used by computers in analytics and automatic verification as well as being human readable and user friendly. This can save time and money by being faster and finding errors earlier.

Questions

To address the objective of my thesis, I broke them down in to two questions. First question came when introduced to this topic and was “What can digital requirements help us with?”

To answer this question, I will start with a literature review of ETO firms. This review will help to understand how such firms are operated and where their bottlenecks are. The question will then be answered by applying the ETO knowledge to the IMF case. This will be

addressed at the end of the literature review and in the conclusion.

The second question is “How shall digital requirements and their corresponding digital product representations be created to become valuable?”.

This question came after I had gotten an insight into today’s requirements and their

documentation. To answer this question, I have been working with employees from the IMF group developing new ways of creating digital requirements. I will establish a framework for making products from a project to digital objects and by working together with the

experienced employees I got feedback on what to improve. When digital objects are created the goal will be to be able to attach requirements to them. By doing this they should become machine and human readable and therefor more valuable. This will be addressed in chapter 6 with model blocks and in chapter 7 I will show how they are valuable when working across companies.

(22)

12 Method

When choosing a research method there are two main approaches, quantitative and qualitative methods. Quantitative methods are mainly used when things can be measured or counted and qualitative methods are used in unmeasurable situations taking a more holistic perspective, looking at the complexity and asking questions like how and why.

I will use a qualitative case study in my master thesis. Case studies have been defined as:

“A way to research a particular field, group, people and situation. The topic of research is studied deeply and thoroughly in order to solve a problem or uncover information. Case studies are a type of qualitative research.” (Postgraduate Studentships, 2021, p. FAQ)

“The qualitative case study is a research method which enables a complex phenomenon to be explored through the identification of different factors interacting with each other. The case observed is a real situation” (Debout, 2016, p. Summary)

“Qualitative case study methodology provides tools for researchers to study complex phenomena within their contexts” (Baxter & Jack, 2008, p. 544)

A qualitative case study approach allows me to explore the theme in depth and detail. It’s a platform that gives me the possibility to look deeper into a problem in a real case. In my master thesis I will focus on a project from the Oil & Gas industry about a real oil platform.

This is a highly complex project where a qualitative case study is a natural choice.

I gathered my data in personal and online meetings with experts from Oil & Gas producers, contractors, suppliers and with researchers from SIRIUS and the University of Oslo. From the Oil & Gas experts I got more than 30 documents of current requirements from a real

anonymized oil field. With them I made a document review where I analysed for patterns that would become valuable in the transition to digital requirements. The COVID-19 situation made it necessary to focus on online meetings, online discussions, literature studies, and a lot of reading to gather background knowledge. I had twice weekly online meetings with the IMF group to discuss and get the views from employees from different expert groups and

departments.

(23)

13

3 Fundamentals

3.1 ISO/IEC 81346

ISO/IEC 81346 is an ISO standard that specifies principles for structuring objects including associated information. It also standardizes rules on how to form reference designations based on the resulting structure. (International Electrotechnical Commision (IEC) 81346, 2009, p. 8) I used this standard in my thesis to create structure for all objects on an oil platform. This structure will make digitizing requirements possible.

The ISO 81346 defines important concepts, such as objects, aspects, and technical systems.

The aspects are divided into function, product, and location. These aspects will be important in my thesis and in the IMF as well. The concepts defined in 81346 make it easier to use standardized language across different companies and more importantly across different disciplines. Having standardized language makes it easier to implement documents and work from others into your own work. A problem that I often discovered during my research is that people had developed their own set of words or even skills to build a set of objects and technical systems. This created a lot of confusion when transferring from one work group to another. I had the opportunity to review a little more than 30 technical documents with requirements and build instructions of objects. Very often the document by itself was written technically correct but a problem occurred when it tried to reference other objects. Here a standardized language with names for objects and aspects could have helped massively. And most importantly having a way of referencing objects in a system between different work disciplines and even different companies would be a big advantage and cost saving measure.

Therefore, the usage of ISO 81346 is very important, and the concepts and aspects mentioned now are crucial for a system like IMF to be feasible and even worthy of trying to accomplish.

(24)

14

3.1.1 Object

An object is an “entity treated in a process of development, implementation, usage and disposal” (International Electrotechnical Commision (IEC) 81346, 2009, p. 11). An object in 81346 can be either a physical or non-physical thing. Most objects in relation to an oil

platform are physical things, for example pipes, pumps, or similar objects. Some objects exist only because of their sub-objects. For example, a nitrogen generator is a system of many objects, in Norwegian called a “pakke”. This system of objects can be defined as its own object when combined with all its sub-objects.

Figure 1 - Illustration of an object (International Electrotechnical Commision (IEC) 81346, 2009, p. 13)

Based on ISO 81346 there shall be no difference in defining an object that is its own physical thing, an object created by its sub-objects or even non-physical things. Each object can be defined based on the needs of the designer or engineer but for each object there should be information associated with it even though it can and probably will change during the life cycle of the object.

An object should be defined when there is a need for this object, and it should be removed again when this object is no longer needed. This will make it possible to track it through its whole life cycle. An important point here is that objects should be created even though there is just a small need for them, because removing objects can also happen when other objects have properties that cover the initially created object.

One important part regarding my thesis is the need for associating information to an object.

This is necessary to connect requirements to an object. As mentioned by IEC 61346-1:1996

“information was not necessarily contained in ready-made documents, but could be

(25)

15 fragmented, put into data bases, from which documents could be put together as needed”

(International Electrotechnical Commision (IEC) 81346, 2009, p. 40). This is also a problem in today’s engineering practices because the information is currently in documents but not ready-made. The information could benefit from being removed from their silos and added to an open database. The goal will be that the company ordering the oil platform will define the requirements and add them to a database. These requirements could then be accessed by the engineering firms and be added to objects with a proper reference designation.

3.1.2 Aspects

An important part of ISO 81346 are the function, product and location aspects mentioned earlier. They differentiate each object in its different parts used by different disciplines in ETO firms.

An aspect is a way to view an object. It can be useful to look at objects from different views when working together, because different people have different needs and knowledge about an object. As seen in the figure below, the object will normally have three sides that visually represent each aspect. When working with one object each side can act like a filter and only show the information that is relevant at the time.

Figure 2 - Aspects of an object (International Electrotechnical Commision (IEC) 81346, 2009, p. 15)

(26)

16

As mentioned earlier objects can also have sub-objects. When looking at one aspect of an object only the sub-objects that have the same aspects will be shown in order to show relevant information. This will become clearer and more important later when we show a working problem from the IMF case and how the different aspects work independently and together.

These three aspects: function, product, and location are the aspects mainly used in 81346 and the aspects I focused on in this case.

The function aspect shows what an object is intended to do or what it does and is marked with a minus “=“ sign when creating references to it. By having a function aspect an object can be created based on what you want it to do without knowing how it will perform its task or where it will be located. This can be beneficial in the beginning of a project where there is only a knowledge of what needs to be done, but not exactly how or where.

The product aspect shows by which means an object accomplishes what it is intended to do and is marked with a minus “-“ sign when creating references to it. Here you often look at what components are implemented or constructed in the system. Whereas in the function aspect you looked at what it does, here you are looking at what component solves which problem in the product and the combination of all components will generate a complete system.

The location aspect shows where an object is intended to be or located in the space and is marked with a plus “+” sign when creating references to it. With this aspect you can figure out where the object is located, and you can with the help of computers now be able to make analysis regarding the location that you earlier couldn’t. For example, we have an object that only can support 1000kg of weight above it. Before, with the document approach you had to find what objects where above it manually. Now a machine has all the location information from an object and knows which objects are attached to it and from the other aspects it can then get the weight of the objects to calculate the mass of all objects together. But this can be the more difficult aspect to create, because sometimes you will need exact x/y/z coordinates of where the object is like in the example while sometimes you only say it is inside of a cube that is inside a room inside a building. This ambiguity needs to be defined by the ones developing the system.

(27)

17 Having three aspects will for example help an engineer who is tasked with making an object that handles the «by-product handling» system. In such a case the engineer knows what the object is intended to do and can create the function aspect of it. But he/she doesn’t know where it will be placed exactly on the oil platform or how it will perform it task. He or she can connect it to its surrounding function objects, for example the «main process» of the «flow processing» system and create a start of a tree that will have to merge with other people’s work on other function objects.

3.2 SCD – Requirements in scope, condition, demand format

As mentioned in the beginning the main proposal is to both have digital requirements and requirements that can be automatically verified. Therefore, we in the IMF workgroup have proposed to write the requirements in the SCD structured form. SCD stands for Scope,

Condition, Demand and is one step in standardizing requirements. Figure 3 is a representation of how a traditional requirement can be transformed from text form to SCD form. The

requirements in an SCD form are defined by having a scope that is something that needs to fulfil a demand. In addition, there may be an optional condition that limits it to a subset of the scope. At the end there is a demand that needs to be satisfied by the scope.

Figure 3 - SCD Syntax (Cameron, Falk, & Kokkula, 2021)

(28)

18

The SCD method “allows for formalized representations of requirement statements” (Fjøsna

& Waaler, 2021, p. 32). Ontologies and semantic technologies will show how the

requirements of all products are connected as well as validate and verify requirements faster and more efficient.

Already before building a product, you can save a lot of time and money by writing

requirements in a structured form. This form makes it possible to verify that requirements are reasonable and necessary for each product. In addition, the owner of the product can much easier check if the requirements fit on delivered products as well. A common format is of great benefit for the users and the transferability between companies.

This is something that also has transferred into the creation of functional system blocks and model blocks because they allow for the connections between the products.

Based on work from Klüwer from DNV (Johan W. Klüwer, 2019) the requirements can be modelled in an ontology, as seen in Figure 4,. It starts with a requirement class where every requirement can get an ID. This class then has a posited by object property to connect the requirement to the organization that has issued the requirement. This can become important when trying to figure out where a requirement came from. If an organization changes their requirements they can also be found more easily.

(29)

19

Figure 4 - SCD clause pattern (Johan W. Klüwer, 2019, p. 2)

Each requirement class has the property has SCD clause. As the name suggests this is just a property to a SCD clause class. This class then again has three properties has scope, has condition, and has demand. SCD are designed so that they can be used in ontologies with the RDF triple from the Resource Description framework (RDF) model. Each triple has a subject, predicate, and object (as seen in Figure 5) that correspond well with an SCD clause as seen in the Figure 4. These SCD clauses are a great start to storing and interacting with requirements but need to be incorporated into a larger system and context to be proven. Here the model blocks should facilitate incorporating the SCD clauses into a larger system.

Subject Object

Predicate

Figure 5 - RDF triple

(30)

20

3.3 Semantic Technologies

The handbook of semantic technologies (Domingue, Fensel, & Hendler, 2011) defines semantic technology as: “Semantic technology provides machine-understandable (or better machine-processable) descriptions of data, programs, and infrastructure, enabling computers to reflect on these artifacts.”

Semantics is the study of meaning (Merriam-Webster, 2021) and comes from French

sémantique which comes from Greek semantikos from semainein “to show by sign” (Online Etymology Dictionary, 2021). It can for example be used in the handling of requirements so that computers can understand what they are and reflect upon them. The requirements are going to be added to existing systems and will have to be processed using a common

language. The semantic technologies can be used to create data structures that machines can easily understand. With the help of this common language the computer and its program can analyse the requirements.

3.4 Ontology

Ontology comes from the word ontos meaning something like ‘being’ and logis meaning logical discourse (Online Etymology Dictionary, 2021). Ontology can therefore be described as: “the metaphysical science or study of being and the essence of things” (Online Etymology Dictionary, 2021)

The term ontology was introduced in philosophy in the nineteenth century and was used to provide category systems (Breitman, Casanova, & Truszkowski, 2007, p. 17), but the idea of it can be dated back much further. Aristotle proposed a category system in his text Categories where he used it to classify all the possible kinds of things.

In the world of computer science and the semantic web, the definition most frequently used about ontology is the one from Thomas R. Gruber: “An ontology is an explicit specification of a conceptualization. The term is borrowed from philosophy, where an ontology is a

systematic account of Existence.” (Gruber, 1993, p. 199). In this scenario conceptualization means to visualize the world, that we want to represent, in both an abstract and simplified view. To do this, one needs to have the objects, concepts and other entities that exist in this

(31)

21 world as well as their connections. There is no universal definition for ontology, so in

addition to Grubers definition there are many others. The W3C, World Wide Web

Consortium, has defined ontology as: “… a term borrowed from philosophy that refers to the science of describing the kinds of entities in the world and how they are related.” (Smith, Welty, & McGuinness, 2021, p. chapter 1). As we can see here, the definitions of ontology are different, but often address the need to create an informal or formal specification of the entities that exist in the world of interest. Some go further in saying that an ontology shall be a representation of a system using logic theory.

The categorisation and classifying from the philosophy view is an equally important part to my thesis compared to the view from the semantic literatures. Where the philosophers are looking at grouping entities into basic categories, such as substance, quantity, and quality. I will group entities from the Oil & Gas Industry based on what their purpose is on an oil platform. I will use categories already existing from previous work in the READI project, but also new concepts defined in the chapter on model blocks.

In a nutshell, ontologies are frameworks for representing shareable and reusable knowledge across a domain. Their ability to describe relationships and their high interconnectedness make them the bases for modelling high-quality, linked and coherent data. During the case study I will have the opportunity to go through a lot of current documentation and will get a better understanding of all the objects and concepts in the world of the Oil & Gas Industry. I will in the chapter of model blocks show a figure of a set of the objects and their connections.

Based on this, I will introduce why I believe ontologies will be valuable to this case and what they can be used for. In addition, I will introduce ideas for what needs to be incorporated into an ontology based on all the documentation and talks I have had with domain experts.

(32)

22

4 Engineer-to-order

I introduce ETO, because it creates both an introduction into how companies that need digital requirements are run and which problems these firms can solve with digital requirements. I will use a literature review on ETO to compare two articles. First an article by Bertrand and Muntslag (Bertrand & Muntslag, 1993) titled “Production control in engineer-to-order firms”

and second an article by Chen (Chen, 2006) titled “Concurrent Engineer-To-Order operation in the Manufacturing Engineering Contracting industries”. Both articles focus on engineer-to- order firms and how their operation is run. From when they receive an interest from another firm to produce a product until it is delivered.

Oil & Gas companies are often ETO oriented and use a lot of time to engineer new products.

ETO projects are one-off projects where components are combined in new and novel ways.

This means high engineering complexity with a lot of calculation and simulation of effects of the developed products. Understanding how Oil & Gas companies work with ETO projects creates a foundation for finding improvements in their work processes. The EPC

(Engineering-Procurement-Construction) contractors for the Oil & Gas firms are the ones standing in between the client and the suppliers and use hundreds of specialist applications to facilitate this. By introducing digitized requirements into engineer-to-order companies the firms in the value chain can hopefully save both time and money.

By comparing these ETO articles, I will showcase the difference between companies who just produce items and the ETO companies involved in the IMF project from the Oil & Gas industry where products need to be defined and specified. The goal will be to create an understanding for you the reader, to see why the ETO distinction is important and how a company can work most efficiently as an ETO company. The articles introduce an ETO framework that makes the creation of products into a standardized process, and I will use that to create a groundwork for how the digital requirements shall be implemented and used. This is especially important to solve before automation of requirements can be tackled.

(33)

23 In addition to introducing ETO, I also expect to show a connection between the findings from these articles and my thesis. Having a digital framework for requirements where everything is available at any time for anybody might make concurrency easier.

I will start introducing the main concepts from the articles and give a summary. This

summary will be important to understand the meaning behind the concepts and how they can be used in the Oil & Gas industry.

By comparing these articles, I hope to be able to gather a better understanding of how complex products should be built and I will give you an understanding of the importance of the ETO production approach for my thesis.

To understand the concept of engineer-to-order, I use the distinction between four different production situations by Sari (Sari, 1981) mentioned in Bertrand and Muntslag: make-to-stock (MTS), assemble-to-order (ATO), make-to-order (MTO) and engineer-to-order (ETO).

(Bertrand & Muntslag, 1993, p. 3)

The first situation is “Make-to-stock” where a firm converts lower-level components and raw materials all the way to end items in anticipation of customer orders. This is the most basic way to produce items and you have to know before you get an order what types of products you shall produce. The second distinction is “Assemble-to-order”. Here a firm also converts lower-level components and raw materials to predetermined level of manufacture but configures the end items to a customer order after receipt of a customer order. This makes it possible for firms to store large amounts of raw material and finish processing them at a later stage. A similar production situation is “make-to-order”. Here a firm still makes products based upon previously engineered designs, but it waits for a receipt of a customer order before it obtains lower-level materials. This makes it possible for the firm to wait and see what types of materials they need and order what is needed. All of these go from having finished

products to buying materials after the order has come in, but all go off previously engineered designs. Then there is the last situation “engineer-to-order” where firms often know very little about what to order or manufacture until after receipt of a customer order and development of engineering specifications. This fits very well for oil and gas firms because each oil platform is different and each item on that platform has to be special for each individual platform. For

(34)

24

example, in highly specialized instances of generators and pumps, where each pump has to be modified to fit on an oil rig, engineer-to-order is the way to figure out what kind of product is needed and how it shall be produced.

In Figure 6 from Chen we can see how make-to-stock (MTS), assemble-to-order (ATO) and build-to-order (BTO) all start after the design process is finished and this is the main

distinction between these three and ETO (Chen, 2006, p. 41). As mentioned before and shown in the figure, ETO starts with a product specification and ends with the final delivery. In the middle, after the product and process design, ETO starts on component fabrication to do the same as an BTO/MTO situation.

Figure 6 - Summary of relevant enterprise operation concepts (Chen, 2006, p. 41)

(35)

25

4.1 Reflections on the articles and their contribution to my thesis

The article by Bertrand and Muntslag (Bertrand & Muntslag, 1993) focuses on a production control framework while the article by Chen (Chen, 2006) makes a framework for concurrent engineer-to-order operation.

As mentioned in the introduction, understanding the difference between engineer-to-order and the other production situations is essential. The most important part about engineer-to-order is that the firm developing a product knows very little about what to manufacture before they get an order from the customer. Bertrand and Muntslag (Bertrand & Muntslag, 1993) are looking into the Manufacturing Resources Planning (MRP II) concept and how it has been tried to be implemented in engineer-to-order situations even though it was developed for make-to-stock and assemble-to-order situations. In engineer-to-order all production activities are customer driven, engineering and design activities are part of the customer order lead time and products are one-of-a-kind.

Dynamics, uncertainty, and complexity are three important aspects of the ETO production situation argue Bertrand and Muntslag (Bertrand & Muntslag, 1993). An ETO production situation is dynamic because it has to anticipate fluctuations in orders. It is also an uncertain situation because they never know what the future demand is and at the beginning of a project the specifications can create an uncertainty because parts are unknown, and they still need to determine capacity and lead time. In addition to this, complexity is a part of ETO production.

Having a non-physical stage together with a physical stage makes it difficult to formalize work and determine progress. All these aspects are not compatible with the MRP II concept.

Another complicating factor is that the product they are making is often one-of-a-kind and specific products must be purchased early on before the full details of the product is clear.

These are all problems, where digital requirements can be part of the bigger solution.

Dynamic situations will be addressed with digital requirements because they are available at any time in a standardized way. The digital requirements will allow firms to make changes on the fly instead of updating multiple documents. The goal with digital requirements is that they shall be automatically verifiable and that makes engineering much faster in a dynamic

environment. Complexity will also be addressed because the digital requirements will be

(36)

26

defined in a standardized way such that they can be used by anybody at any time. Uncertainty would not be solved by this but it will hopefully make the uncertain time periods shorter because the products can be defined and developed faster.

Bertrand and Muntslag describe why MRP II do not work in an ETO situation. Basically because, MRP II needs a Master Production Schedule (MPS) and a Bill-of-Materials (BOM) (Bertrand & Muntslag, 1993). Both of these assume that all required information is available, and nothing is uncertain. But ETO firms are inherently uncertain and their BOMs are

incomplete or only roughly known at the start of a project. Therefore, MRP II systems are not applicable to ETO situations. MRP II systems are for standard products and not one-of-a-kind products where information is gathered during development and engineering. Such as is often the case in the oil and gas industry.

To design the logistic chain for an engineer-to-order situation Bertrand and Muntslag define three steps: defining the operations, identifying the goods flow control (GFC) items and production phases, and establishing the production units. (Bertrand & Muntslag, 1993) For the production phases there are five generic phases and related GFC items. Phase 1 is the development of a global conceptual product design during the tender stage. Then in phase 2 is the preparation of a detailed conceptional product design after a tender is accepted, this results in a detailed view of the design of the product. After that, phase 3 starts with the completion of a detailed product specification in the form of engineering drawings and bills of materials.

This phase is important on the GFC level because the product uncertainty is now reduced to zero. The second to last phase, phase 4, is concerned with the manufacturing of the

components which are required for the final assembly of the product. In this phase it is desirable to report to the goods flow control with updated information to allow for

coordination of the component manufacturing and assembly activities. In the last phase the finished product gets assembled.

Especially phase 3 as well as phase 2 shall get better with digitalized requirements and model blocks that I will introduce in chapter 6. Having standardized model blocks for different products should make it easier to reuse old parts and should make phase 2 faster and more

(37)

27 accurate already from the beginning. This flows than into phase 3 where all the engineering drawings are created based on the model blocks and they shall therefore be created faster and more accurate because they can be verified on the fly.

For the logistic chain there is also a need to establish some production units. These are needed based upon the generic production phases defined above. The first production unit is a

combination of the first and second production phase and is called Conceptual Design. The second production unit is Product Engineering, and it comes from the third production phase.

This production phase is significantly different from the previous and subsequent one so the resources cannot be shared. Then there is the third and fourth production unit, respectively Component Manufacturing based upon production phase four and Assembly based upon production phase five. This generic logistic chain is then used as a reference model in the Bertrand and Muntslag (Bertrand & Muntslag, 1993) article to develop a production control framework.

There are two levels of production control in the production control framework, Production Unit Control (PUC) and Goods Flow Control (GFC). In GFC there are three production control aspects identified, Aggregate Production Planning (APP), Operational Production Planning (OPP) and the interface between Production and Sales. APP is the medium-term matching of required resource capacity with available capacity. These changes are important to anticipate as early as possible in ETO situations. OPP is the coordination of materials and capacity scheduling for the flow of goods. The OPP focuses primarily on the resource capacity aspect in the start of the logistic chain and focuses on materials only for critical materials with a long delivery lead time. Having a good working interface between

Production and Sales is important, especially in ETO situations and during the tender phase.

The customer may change his specifications, other customer orders may have been accepted by the time the tender is finalized and capacity requirements may change in the tender process. In all of this it is important for Sales and Production to have a working interface to revision and reconfirm relevant conditions before a customer order.

Now that the production control functions have been decided they can get more substance with a decision structure. A decision structure for an ETO manufacturing situation can be divided into four key production control decisions: 1. Customer order acceptance and due date

(38)

28

assignment, 2. Sub-order assignment and PU outsourcing, 3. work order release and 4. work sequencing. This decision structure is an explicit part of the control framework and hereby the customer orders can be controlled in a top-down manner. Having a delegation of production control responsibilities to the shop floor is very important in an ETO situation because the people close to the production processes can give the best response based on ETO

characteristics (uncertainties, etc.) The delegation of decision-making responsibilities is explicitly included in the decision structure. The first key decision is taken by managers and the second key decision is then taken together with the production managers. The third decision is taken by the head of each production department and the fourth decision is taken by each group leader together with individual workers.

This decision structure will not be impacted by the digital requirements from this thesis. But the way decisions are made can be influenced, because they can be implemented faster and more precise with verifiable digital model blocks of products. For example, the sub-order assignment and outsourcing decision part is highly relevant in the Oil & Gas industry where many products are manufactured by outsourced companies. Here Bertrand and Muntslag (Bertrand & Muntslag, 1993) talk about how it is important to create sub-orders to both have a link between the non-physical and physical stages in the logistic chain and to review the first key decisions based on new information and take corrective measures. Both roles should the digital requirements and its model blocks be able to solve. The link between the stages is solved better with digital requirements because the handover is “cleaner” and more precise. In the current world with documents there is a higher probability of miscommunication and errors sneaking in because of the sheer number of documents. The possibility to review decisions after the first decision, but also at any time in the project, becomes much easier when the work that is done can be verified automatically by computers.

The conclusion by Bertrand and Muntslag (Bertrand & Muntslag, 1993) is that MRP II systems are not suited for ETO situations. And that their framework for production control in engineer-to-order manufacturing plants can help overcome that. This framework is based on the design of the logistic chain, the distinction of different levels of control and the

identification of four key production decisions.

(39)

29 For the digital requirements and my model blocks to function properly it is recommended that the companies using it also implement something like the framework from Bertrand and Muntslag (Bertrand & Muntslag, 1993). By doing that they can work more efficient on ETO projects.

The article by Chen starts off with an important research background into product life cycle, operation modes and related manufacturing operation concepts (Chen, 2006). He intends to define the concept of concurrent ETO operation, and it proposes a foundation for design and development of an effective concurrent ETO operation framework. (Chen, 2006)

The product life cycle can be divided into 8 phases; need analysis, product specification, product design, process design, component fabrication, assembly, delivery, service. The first four phases are typically considered engineering/design tasks, while component fabrication and assembly are considered manufacturing tasks. These phases are important to understand the differences between ETO and the other operation modes/situations. Chen (Chen, 2006) defines in the same way as Bertrand and Muntslag MTS, MTO, ATO and ETO. Chen (Chen, 2006) also defines a concurrent ETO as an ETO operation in which both design and

manufacture processes occur in parallel, in order to optimally minimise the product development time that spans a product specification and delivery of the final product. In figure 1 from Chen it is clearly defined where each operation mode starts. ETO starts with the product specification, BTO after the process design, ATO after the component fabrication and lastly MTS at the end starts after product assembly. Later in the article Chen mainly focuses on ETO and concurrent ETO. (Chen, 2006)

Then Chen introduces some related manufacturing operation concepts (Chen, 2006). First is the concept of mass customisation. It is a philosophy in which products are designed and made to customer’s need while the operation still is running at mass production rate. This makes it interesting to use for companies that produce products with similar product

structures that still have differences. Mass customisation can be used if generic work elements and process are properly standardised.

Another related concept is concurrent engineering. It aims to shorten product development lead time by performing engineering activities concurrently, in parallel. Working in parallel

(40)

30

complicates already complex ETO firms’ operations and because scheduling and control is convoluted, better lead time is not always guaranteed. This is what Chen then brings into the concurrent ETO operation framework. (Chen, 2006)

Figure 7 - Concurrent ETO operation framework (Chen, 2006, p. 49)

Hereby Chen (Chen, 2006) starts introducing the concurrent ETO operation framework. The goal of a concurrent framework is to run an ETO operation at the efficiency and cost

effectiveness as a mass production operation while minimising lead time. Engineering is treated as a production activity so planning and execution of sales, engineering and

(41)

31 manufacturing operations happen in parallel. To have a concurrent ETO operation you need a set of common attributes, you need an incremental work planning and scheduling, you need to be able to handle frequent managerial and technical changes, your firm needs to engage in mass product/process customisation, your firm needs to have a close collaboration with customers, suppliers and subcontractors and management of product lifecycle data and history.

For the proposed concurrent ETO operation framework there are four major business processes: sales operation, production operation, engineering operation and manufacturing operation. Bidding is a production activity in a concurrent ETO operation. The sales operation is the driving force in this framework because it receives requests for quotation and makes a bid back. Each sales process works together with the production operation, the production coordinates with the engineering operation for preparing a specification and estimation of product cost. Then the production figures out the resource requirements and the sales operation make a bid. If the bid gets accepted this same order is converted into production orders for the production operation.

As shown in the Figure 7 by Chen (Chen, 2006) above, the dashed lines show the workflow of cost/lead time analysis in a bidding process, while the solid lines show the workflow for a production order. Bidding is a complex task in an ETO operation, but the details gained from this make it easier in the production phase because one can turn the customer order directly into production orders.

What makes this framework concurrent is the two parallel paths in the engineering operation:

quality engineering and product/process design. The product/process path starts with the product specification and goes than through engineering analysis, product design and process design. The quality path starts at the same time as the product/process path, and it starts with a QA guideline for the product before going to a process QC plan.

By having a concurrent operation, the goal is that product development is faster. The bottleneck will still be the quality control of the products. Here digital requirements with

(42)

32

model blocks can be part of the solution. They can make handover between process design and quality engineering faster and quality engineering more precise and therefore faster.

Even though the concurrent ETO operation is mostly focused on the producing of products and planning for material, work and scheduling, digital requirements will facilitate possible changes needed for the product during the production.

4.1.1 Analysis of the articles

Bertrand and Muntslag defined ETO as knowing very little about what to order or manufacture until after receipt of a customer order and development of engineering specifications. (Bertrand & Muntslag, 1993) Chen defined ETO as a product development process that starts with a product specification and finishes with an engineering design as its deliverable. (Chen, 2006) So here we can see that both agree on the definition, but Chen goes deeper into it and says that it is usually limited to an engineering design process, and it does not include the manufacturing phase of materials acquisition, fabrication, and assembly. Chen also mentions the use of prototyping in the design process, but they are normally not a

deliverable item. (Chen, 2006) In the oil and gas industry prototypes are also used and they may also become a deliverable item. More on that later.

Chen (Chen, 2006) introduces the concept of concurrent ETO, which is different from

conventional ETO. It is still a make-to-order operation that starts with a product specification and finishes with delivery of a customized product, same as both Bertrand and Muntslag (Bertrand & Muntslag, 1993) and Chen (Chen, 2006) define as conventional ETO. But it is different, by carrying out engineering and manufacturing processes concurrently and treating them both as a production activity. The important part of the concurrent ETO is the goal to make the lead time shorter, while keeping the integrity and stability of the project intact.

Having a concurrent ETO should save valuable time and make a firm more attractive for potential buyers.

(43)

33 Both articles agree on the importance of Bill-of-Materials and the difficulty in making them in ETO operations because, so little is known about the final product. BOMs make it possible to calculate the required production and are valuable in making an informed bid where it is shown what is needed to be produced. Bertrand and Muntslag mention that the project-BOM is incomplete at the beginning of the project and that MRP II systems can’t handle that.

(Bertrand & Muntslag, 1993) But having both a standard BOM and historic BOM are

valuable to create the project BOM. Though they mention that having all three of these BOMs combined will create an immense and polluted database where you cannot have control over work items. Chen also argues that the MRP estimates material cost and delivery lead time for each BOM item and that the full BOM can be released incrementally to trigger a request for both material and an acquisition process in the concurrent ETO operation. (Chen, 2006) Here Bertrand and Muntslag and Chen differ a little bit in that Bertrand and Muntslag try to make as much of the BOM as soon as possible with the help of standard and historic BOMs while Chen makes them during the ETO operation. (Bertrand & Muntslag, 1993) (Chen, 2006)

4.2 Conclusion of the articles and their importance for my thesis

Most of the oil and gas industry are ETO firms, they almost always need new or different products that haven’t been developed before. Often the customer only has specifications, and they need a product that fulfils these specifications. In my thesis I will look into how there can be better digitized requirements that can be automatically verified. By having an ETO

framework that makes it clear where specifications are used and where they can become problems, I have gained valuable information for my thesis.

As talked about by Chen, the product life cycle is important and the lead time for products can be reduced with the concurrent ETO framework. (Chen, 2006) Product specifications need to be precise at the beginning to make it easier to develop the product and at the end they need to be verified against the built product to ensure the product fits the order. Specifications need to be good and should be standardized. And without good specifications that cannot be used across the different firms, reducing the product lead time becomes impossible.

(44)

34

This concurrent ETO framework can maybe be used in the Oil & Gas industry by

implementing the standardized models from this thesis. The decision to use a concurrent ETO way of working will be up to the firms, but either way the standardized models shall facilitate better sharing of information between the firms. Having better models where requirements are stored machine readable and verified at any stage in the life cycle, should facilitate a

concurrent ETO framework. For the concurrent framework to function well, it depends on handover of documentation many times. The proposed solution in this thesis uses

standardized models and allows them to be stored in a centralized master data storage. This should make a concurrent workflow easier because there will be less information and knowledge sharing. Where information is the actual data stored in the documentation that is transferred and knowledge is the implicit information created by the engineers in today’s workflow.

As mentioned by both Bertrand and Muntslag (Bertrand & Muntslag, 1993) and Chen (Chen, 2006), ETO operations are uncertain and complex. Having standardized specifications in the beginning will make it easier to have a better MRP and BOM. Bertrand and Muntslag argue that uncertainty is different from complexity but having a high complexity will inherently bring uncertainty. (Bertrand & Muntslag, 1993) This will again be solved by having

standardized processes where the producing firms can easier plan their work and maybe have a better product at the end due to a common understanding of the requirements.

For the oil and gas industry having standard BOMs is important so that multi firm cooperation is possible. When the project is handed off to the companies producing the components, making changes becomes more difficult because there is little communication between the producing companies. But we also need to be open for following Chen’s (Chen, 2006) approach with having materials added to the BOM during the development of the product.

All of this can be tied to the digital requirements from this thesis. Based on the digital

requirements and the ISO 81346 standard there will be a unique identifier for each part of the product. This identifier can then be used throughout the life cycle of the development. With Chen’s (Chen, 2006) approach of adding more products to the BOM during the development, having a digital specification with unique identifiers of the product, it can be easier to add, remove and modify the product during the development. This is because the computer system

(45)

35 will manage all connections and possibly automatically verify that the new component fits into the whole product.

Something mentioned by one of my discussion partners in the oil and gas industry is that prototypes can become deliverable items, because the building blocks to get to the deliverable item are not standardized and one needs to create prototypes because almost each deliverable is one-of-a-kind and needs to be checked against the specifications. This goes a little bit against the concept of ETO because it has nothing to do with producing the final item. But this can also be seen as an important step in verifying specifications and checking for quality control concurrently as mentioned by Chen. (Chen, 2006)

By using these thoughts about ETO in this thesis’s case study I will look at how to model the design process and how to best create models of the complete system that must be built.

4.2.1 What needs to be better in the future based on ETO’s principles

Both Bertrand and Muntslag (Bertrand & Muntslag, 1993) and Chen (Chen, 2006) agree that in the beginning of an ETO there has to be a part where the product gets specified, consisting of an engineering and a design phase. This is the most important part for this thesis and is where the most time has to be spent to make the process easier and faster later on. In todays world there are multiple firms working together on the same end product (in our case an oil platform). This is due to the size and complexity of an oil platform that different firms have different expertise and work on different parts of the same product.

The ETO process is more dynamic than the other ways of producing products. When multiple companies are involved, one problem that exists in the current way of working is that there doesn’t exist one master of the complete product. In conjunction with an ETO process the Oil

& Gas industry has a lot of wasted time because the individual companies engineer their products and then have to come together to verify their work against each other. This is mostly in very big projects, but even in very small projects with an individual company creating the platform the need for one master can still exist because even inside one company

Digitized requirements for automated verification

Digitized requirements for automated verification

A real-world case study

Kai Arne Schröder Myklebust

Master of Informatics:

Programming and System Architecture 60 credits

Department of Informatics

The Faculty of Mathematics and Natural Sciences UNIVERSITY OF OSLO

Digitized requirements for automated

verification

Summary

Foreword

Table of contents

Important terms

1 Introduction

1.1 My contribution

1.2 My work processes

2 Research

3 Fundamentals

3.1 ISO/IEC 81346

3.1.1 Object

3.1.2 Aspects

3.2 SCD – Requirements in scope, condition, demand format

3.3 Semantic Technologies

3.4 Ontology

4 Engineer-to-order

4.1 Reflections on the articles and their contribution to my thesis

4.1.1 Analysis of the articles

4.2 Conclusion of the articles and their importance for my thesis

4.2.1 What needs to be better in the future based on ETO’s principles