Process Development in Hydrogen

Production

Axel Lindwall

Mechanical Engineering, master's level

2022

Luleå University of Technology

Department of Engineering Sciences and Mathematics
Preface
This thesis was completed in cooperation with H2 Green Steel in the spring of 2022, at the
technology team based in Stockholm, Sweden. I want to express my gratitude to my supervisor
Elsa De Geer for her full support and significant contribution to the project. Magnus Karlberg
at the Luleå University of Technology deserves a big thank you for his guidance regarding the
academic part of the project.

Finally, I would like to thank my friends and family for always supporting and inspiring me. I
would also thank my grandmother, Hilkka Klingefjord, who passed away during the spring. While
sharing my plans for the spring during the holidays of 2021, her excitement and support for the
thesis acted as a pole star consistently throughout the spring and for future opportunities.

Stockholm, June 2022

Axel Lindwall

i
Abstract
H2 Green Steel AB was founded in 2020 to build a large-scale green steel factory in Boden,
Norrbotten, Sweden. The factory consists of green hydrogen production, iron production and
steel production. In 2030, the factory’s annual steel production will be 5 million tonnes annually.
The objective of the thesis was to build a concept to improve a recommendation for a Hydrogen
production site in an early stage of engineering. It included improving the understanding and basis
for three criteria. The first criteria consisted of technical and customer requirements, seeing the
requirements for the specific application of hydrogen as the critical factor. The second criteria
consisted of further investigating how existing interfaces and utilities can be used in hydrogen
production and building the basis for qualification. The third criteria consisted of adapting the
concept to existing internal design tools by building it forward compatible. The thesis was initiated
by bench-marking possible activities related to the recommendation acting as technical support and
extensions to existing solutions. The research approach used was Design Research Methodology
(DRM), held as the framework for execution. The result from the thesis delivers a database model
built upon three linked packages providing a methodology of increased technical information,
forward compatibility and a modular approach for design.

ii
Contents
1 Introduction 1
1.1 Problem background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Purpose and goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Disposition and confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Theoretical framework 4
2.1 Design Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Research Classification RC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Value chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Hydrogen production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Hydrogen Direct Reduction of Iron Ore . . . . . . . . . . . . . . . . . . . . . 8
2.3 Flow Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Process flow diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Piping and Instrumentation Diagram . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Procurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Request for Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Request for Quotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.3 Request for Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Plant breakdown structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Methodology 12
3.1 Design Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1 Research classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2 Descriptive Study I (DS-I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3 Prescriptive Study (PS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.4 Descriptive Study II (DS-II) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Results 15
4.1 Design research methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1 Descriptive Study II (DS-II) . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2 Configurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.3 Flow diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.4 Usage of the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Discussion 26
5.1 Work Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6 Conclusions 28
6.1 Addressed factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 Future work and implementation 30

iii
Abbreviations
Abbreviations frequently used in the thesis

Explanation Abbrevation Meaning

H2 Green Steel H2GS Company name
Design research methodology DRM Framework of research
Research clarification RC Initial problem understanding of DRM
Descriptive study I DS-I Influencing factors
Prescriptive study PS Model of the product
Descriptive study II DS-II Evaluation and conclusions
Original equipment manufacturer OEM Company that produces parts and equipment
Capital expenditures CAPEX Money to spend on usually fixed assets
Operating expense OPEX Money to spend on usually operational costs
Request for information RFI Document to collect written information of supplier
Request for quotation RFQ Document to collect quotation
Request for proposal RFP Document that solicits proposal
Request for bid RFB Document to initiate a bidding process
Balance of plant BOP Supporting components to plant
Process flow diagram PFD Plant design of components
Piping & instrumentation diagram P&ID Detailed engineering of connecting interfaces
Plant breakdown structure PBS Breakdown of a project into smaller components

iv
1 Introduction
1.1 Problem background
Steel production accounts for 25% of Europe’s industrial CO2 emissions, which is more than the
Nordics countries total CO2 emissions or more than all flights departing from the EU. Therefore,
decarbonisation is a must for the industry, and disruptive technology will be a key enabler. H2
Green Steel (H2GS) will be a fully integrated, digitalised, and automated greenfield steel plant.
By bringing together raw materials, renewable energy, leading expertise, and artificial intelligence,
H2GS aims to bring emissions down to zero. That’s why H2GS plans to build a large-scale
production site for green steel in collaboration with customers across numerous segments, including
automotive, commercial vehicles, white goods, furniture, and industrial equipment.

1.2 Problem formulation

In a conventional approach for a purchaser within similar industries to H2GS, lead times often
occur in the early stages. One example could be when an Original Equipment Manufacturer
(OEM) requires information for an installation. This information in terms of requirements can
be summarised in the general term as RFx, including terms such as Request for Proposal (RFP),
Request for Information (RFI), Request for Quotation (RFQ), and request for Bid (RFB). H2GS
identified that this process has the opportunity to be increased in technical measures, which
ultimately contributes to reduced lead times in the purchasing process. Enabling this requires
thorough information gathering and a holistic approach to early procurement.

Figure 1 highlights the timeline of a high-level procurement process in terms of equipment.

1. In person meeting
Initial step of the buying process

2. H2GS sends RFI

Initiation of the configuration. The level of detail is for indicative cost estimation based on
the desired performance

3. Enter data in optimiser

Based on the details shared from RFI, current optimisation can be initiated

4. Optimiser recommends configuration

A recommendation is made based on financial figures and demanded production

5. Supplier RFQ
After commitment from customer, H2GS initiate contact with supplier with an RFQ

6. Select OEM
Selection of supplier

7. Send offer
Send offer to customer

1
 Figure 1: Timeline for procurement. Green square subjects the scopes timeline

By taking Figure 1 into consideration, the process is dependent on the fact that an RFI has been
sent and is supposed to deliver results as support for choosing OEM. Therefore, three steps are
highlighted to be part of the thesis from the timeline in Figure 1.

1.3 Purpose and goals

The thesis aims to implement a technical database for Hydrogen production, including requirements,
plant configurator and flow diagram. The database has to be defined in data formatting, enabling
the deliverables to be implemented in a broader perspective. Furthermore, these processes allow a
company, acting as a non-equipment provider, to strive for fully defined RFQs for their supplier,
ultimately reducing lead times. Three work packages will be developed to reach the purpose of the
thesis, see Figure 2.

• Requirements
Establish a supplier data requirements model for H2 Green Steels sub-tier suppliers, including
requirements for process and feeds.

– Plant breakdown structure

Develop a formatting standard for flows and streams in accordance the with an equipment
structure

• Flow diagrams
Build visual and practical flow diagrams, combining streams and utility consumption and
equipment requirements. The model should apply several electrolysis techniques and outline
shared components and streams.

• Configurator
A configurator to the database enables requirements that rely on streams to be summarised
for further evaluation, including the list of equipment.

2
 Figure 2: Workpackages for the thesis

By capitalising on the technical knowledge that these work packages lead to, the value proposition
for H2 Green Steel is strengthened and contributes to their operations as a technical partner.

1.4 Limitations
The timeframe for the thesis is limited to 20 weeks, and on the request from the company, the
thesis framework is limited to hydrogen production. This entails procurement, ongoing operations
and expected life-cycle assessment.

1.5 Disposition and confidentiality

On the request from the company, the performance figures presented in the report are not, by any
means, related to H2 Green Steel AB’s suppliers or its internal figures. The given models are partly
conducted with arbitrary data imported from Irena [1].

3
2 Theoretical framework
The applied theoretical framework of the project is found below.

2.1 Design Research Methodology

The DRM research method is meant to support a more rigorous approach in a design research project.
It consists of methods and guidelines that can be used in process development. These framework
models rely on ultimate improvements in design practice, practice management, education, and
outcomes. The DRM model intends to have a distinction in process design methodology in four
distinct stages. They follow as; Research classification (RC), Descriptive study I, Prescriptive
Study (PS) and Descriptive Study II. The Figure 3 showcases the links between these stages,
including basic means and outcomes. An example with researchers aiming to improve how the early
stages of design processes are executed is used to give a practical example of how the DRM can be
implemented in a process. The underlying assumptions for the researchers are based on the general
knowledge about design and partly on beliefs. They follow as; the task clarification is a crucial
activity where the quality has a direct improvement effect on the design process. Fulfilling this
will lead to a "more" successful product. The researchers have also found the currently available
design support ineffective for the scope. Therefore, a decision has been made that the researchers
won’t immediately approach the initial idea - the development of a requirements management tool.
Instead, a systematic research approach will be applied in line with the framework in Figure 3.

Figure 3: Framework for DRM based on Lucienne T.M. Blessing PhD [2]

2.1.1 Research Classification RC

This stage is subjected to seeking evidence or at least indication that can support assumptions from
researchers to compose a scope with a realistic goal that is worthwhile to investigate further. This
is done by researching literature and seeking factors influencing the project’s task classification,
leading to success. One example that is emphasised in a way to describe wrong stated criteria for a
product’s success is "increase in profit". However, given the research project’s time frame, this
is an invalid measure in the RC stage. Instead, a criterion such as "reduction in time-to-market"

4
could be a useful proxy, hence the perspective. Therefore, the researchers are expected to have
their deliverable from the RC stage as follows:

• Current understanding and expectations:

– Initial Reference Model;

– Initial Impact Model;
– Preliminary Criteria.

• Overall Research Plan:

– Research focus and goals;

– Research problems, main research questions and hypotheses;
– Relevant areas to be consulted;
– Approach (type of research, main stages and methods);
– Expected (area of) contribution and deliverables;
– Time schedule.

Descriptive Study I (DS-I)

This stage demands that the researchers have a clear vision and goal to review the earlier literature
for more influencing factors. The idea is to state which factor(s) should be addressed to improve
the stated task classification for effectiveness and efficiency by not determining these factors and
investigating further deeper. By elaborating more on the earlier example from [2], it is not by
interest to find evidence that more time spent on modification increases the "Time-to-market".
Instead, it’s desirable to make logical assumptions supported by other literature findings suggesting
that it’s a plausible assumption quote.
The researchers are expected to have their deliverable from the DS-I stage in accordance with [2]
as follows:

• A completed Reference Model, Success Criteria, Measurable Success Criteria and Key Factors,
that:

– Describe the existing situation and highlight the problems;

– Show the relevance of the research topic;
– Clarify and illustrate the main line of argumentation;
– Point at the factors that are most suitable to address to improve the situation;

• An updated Initial Impact Model;

• Implications of the findings for the development of support and/or for the evaluation of
existing support.

5
Prescriptive Study (PS)
In this stage, the researchers use their increased understanding of the existing to correct and
elaborate on the initial description of the desired situation. The vision of the stage description is to
address how factor(s) in the situation would lead to the realisation of an improved situation. The
methodology relies partly on developing possible scenarios targeting various factors. By looking at
the practical example, the researchers decided to improve the quality of the problem description as
the most promising factor to address. This is founded on the argument that this will; "reduce the
number of modifications, which in turn should reduce design time, which eventually should shorten
time-to-market and increase product success through increased profit"[2]. With confidence, the
researchers can now start the systematic development to improve the problem formulation. These
activities are interlinked with the stated factors in the DS-I stage; the well-developed description of
the desired situation; and their experience in developing design support. To help the researchers to
develop support systematically, the researchers choose to follow a design methodology. After a task
clarification followed by a conceptual design stage, the researchers now have a concept of a software
tool - the intended support. The software tool has its purpose of encouraging and supporting the
problem definition. After a first evaluation of the tool, it could be said that the actual support
shows that it has been developed correctly. What has to be still considered is that this stage is
built upon assumptions that have been based on the desired situation. [2]
The researchers are expected to have their deliverable from the PS stage in accordance with [2] as
follows:

• Documentation of the Intended Support:

– Intended Support Description: what it is and how it works;

– Intended Introduction Plan: how to introduce, install, customise, use and maintain the
support as well as organisational, technical, infrastructural pre-requisites;
– Intended Impact Model

• Actual Support: workbook, checklist, software, etc.

• Documentation of the Actual Support;

– Actual Support Description;

– Actual Introduction Plan;
– Actual Impact Model;

• Results of the Support Evaluation;

• Outline evaluation Plan.

Descriptive Study II (DS-II)

This stage aims to understand further the support tool’s impact and ability to realise the desired
situation. The researchers take two empirical studies into account to evaluate the actual usage of
the support tool. The first study investigates the applicability of the support tool with the central
question; Can the software be used to encourage and support high-quality problem definition. The
second study investigates further the usability of the support tool in terms of its success and how

6
well it has answered the earlier stated criteria. The main question is whether less time is spent on
modifications and how this has impacted the time-to-market. By doing these empirical studies, the
researchers found out that the support tool has a good impact in terms of applicability but lacks in
terms of everyday usability. Researchers found that the underlying reason for that is that several
effects were not considered, for instance, the time needed to keep the problem definition up to date.
Therefore, following the DRM framework, an iterative step of DS-1 is now suggested.
The researchers are expected to have their deliverable from the DS-II stage in accordance with [2]
as follows:

• Results of the Application Evaluation;

• Results from the Success Evaluation;

• Implications and suggestions for improvement for:

– The Actual support;

– The Intended Support, its concept, elaboration and underlying assumptions;
– The Actual and Intended Introduction Plan including introduction, installation,
customisation, use and maintenance issues;
– The Actual and Intended Impact model;
– The Reference Model;
– The criteria used.

• Actual Support: workbook, checklist, software, etc.

• Documentation of the Actual Support;

– Actual Support Description;

– Actual Introduction Plan;
– Actual Impact Model;

• Results of the Support Evaluation;

• Outline evaluation Plan.

Iterations and variations

The example described in RS, DS-I, PS and DS-II neglect the iterative and parallel activities for a
simplified main flow of the DRM framework. It’s also mention-worthy that the example doesn’t
communicate that a starting point can be in each stage. One shall not see the DRM framework
as a set of stages and support methods executed linearly and rigidly, hence there are well-known
negative effects from design methodologists. Iterations increase understanding, and stages are
executed in parallel for a more efficient process. This is also known as concurrent or simultaneous
Engineering. [2]

7
2.2 Value chain
H2 Green Steel will build a Hydrogen direct reduction iron plant (HDRI), fed to an Electric arc
furnace (EAF) for steel making and a Hydrogen production site. With these three production
steps, it’s possible to produce steel with a 95% Carbon Dioxide emission reduction. [HSGS] The
HDRI-EAF is the most viable alternative to traditional steelmaking in an intermittent energy source,
given the possibility of flexible hydrogen production. Hydrogen as an energy carrier also has a wide
area of use in other sectors of energy systems, such as chemical production and transportation. [3]

Figure 4: Value chain based on H2 Green Steel [4]

2.2.1 Hydrogen production

The demand for Green Hydrogen for steel production is supplied through water electrolysis on site
through split water molecules into Hydrogen and Oxygen, as shown in the reaction formula (1). [3]

H2 O(l) −→ H2 (g) + 1/2O2 (g) (1)

To increase the production rate, multiple cells of electrolysers are merged, creating a cell stack.
These cell stacks are systems including underlying components, such as tanks for electrolyte and
cooling water. Hence the extensive volumetric attribute of Hydrogen, high compression is desired
for storage. This also applies to the input stream of Hydrogen for the reduction of iron ore.

2.2.2 Hydrogen Direct Reduction of Iron Ore

Hydrogen is used in an HDRI-EAF system as a reducing gas in a moving bed shaft furnace. The
reaction is endothermic and requires energy in the form of heat to carry the reaction forward.
Therefore, the Hydrogen is pre-heated to 950◦ C before entering the direct reducing iron (DRI)
reactor. The reaction equation found in (2) - (4). [3]

3F e2 O3 (s) + H2 (g) −→ 2F e3 O4 (s) + H2 O(g) (2)

(1 − x)F e3 O4 (s) + (1 − 4x)H2 (g) −→ 3F e1−x O(s) + (1 − 4x)H2 O(g) (3)

F e1−x O(s) + H2 (g) −→ (1 − x)F e(s) + H2 O(g) (4)

8
2.3 Flow Diagrams
2.3.1 Process flow diagram
A Process flow diagram (PFD) is the layout designer’s best practice for designing an initial plant.
The methodology for creating the graphic interface is to start outlining the hierarchy in the unit
operations from top left to bottom right, downstream. The standard that applies to Europe and the
UK is the British standard for engineering drawings (BS 5070) and BS EN ISO 10628. Compared to
the Piping and Instrumentation diagram (P&ID), described in Section 2.3.2, the PFD restrains unit
symbols simplified using standard P&ID symbols or blocks. The interconnecting lines represent the
medium’s flows, temperatures, and composition but have their primary purpose of summarising the
mass-/energy balances.[5] Pumps are considered the main components in the diagram, as shown in
Figure 5.

Figure 5: Process flow diagram (PFD) for the pH correction section of a water treatment plant,
based on Moran [5].

2.3.2 Piping and Instrumentation Diagram

The P&ID showcases the instrumentation, unit operators, valves, process piping, connections,
size, materials, and flow directions. The connecting lines can vary symbolically and topologically,
meaning that the methodology of creating the graphical interface isn’t restricted as on a PFD.
The P&ID acts as the process engineer’s signature document and is excepted to develop over
the timeline of the plant design development. The P&ID outlines physical and logical flows and
interconnections, leading to an intuitive standard for other process engineers and software engineers.
It also complements the PFD in terms of layout, whereas the P&ID includes pipe dimensions,
materials and further details that the PFD doesn’t consider. [5]

9
 Figure 6: Extract from a piping and instrumentation diagram (P&ID), based on Moran [5].

2.4 Procurement
2.4.1 Request for Information
A Request for Information (RFI) is a business document acting as a solicitation to suppliers with
information on products and services they can provide. The RFI is the first stage of the process,
where the demand and current interfaces are shared, ranging, e.g. from the desired production to
available substreams. In addition, an RFI is often used as a research phase at an early stage to
investigate different solutions and limitations. [6]

2.4.2 Request for Quotation

A Request for Quotation (RFQ) follows the RFI as a solicitation sent to one or several suppliers
(depending on the project size). The stage seeks to initiate a bidding process for a contract to
supply specific products and services as a potential solution for demand or problem. The RFQ
responses in a typical procurement process will ultimately provide the bases for benchmarking and
judging between suppliers. [6]

2.4.3 Request for Proposal

A Request for Proposal (RFP) is an announcement for a supplier’s project, defining details and
the qualified suppliers involved. It’s often recognised as the launch for, e.g. a production site,
with the exact specifications.[6] The RFP shares methodological similarities with the Request for
Bid (RFB), acting as an invitation to any qualified supplier. The main difference is that the RFB
doesn’t request projected costs and promises, whereas the RFP considers these estimates. [7]

2.5 Plant breakdown structure

Due to the rapid development of the technical systems at H2GS, one criterion to consider was
forward compatibility. These systems may be plant design tools and control systems, which could
be implemented in the system architecture for the future. Practically given, each process equipment
(or component) in the system has to be assigned with the internal procedure of tagging strategy. A
tagging strategy is conducted through a Plant Breakdown Structure (PBS), including a layer-based
structure for a planned site. Each layer has assigned identification; this can be applied to the

10
foundations and equipment. One example of a layer-based structure is shown in Figure 7 as a Work
Breakdown Structure (WBS), which is another word for a PBS.

Figure 7: Unified WBS for integrated lifecycle building asset management model based on
Maha Al-Kasasbeh [8].

11
3 Methodology
The initial thesis proposal suggested four work packages considered as mission statements for the
project. However, after the start, it became clear that those were outdated since a project had
already begun solving the main topics. Therefore the Design Research Methodology (DRM)
became the framework for developing a new topic for the thesis.

3.1 Design Research Methodology

The theoretical framework from the DRM can be found in Design Research Methodology.

3.1.1 Research classification

The Research classification (RC) process was initiated with the primary objective of formulating
a problem, including a connection to academia and a master’s profile. This was made firstly by
a needs analysis. To begin the needs analysis, an initial target was formed of how and where a
potential solution could be viable in the procurement timeline. This target was formulated as a
scenario together with the supervisor at the H2GS and was stated as;

How can a recommendation for a Hydrogen plant be given based on:

• ..technical and customer requirements

• ..existing interfaces and utilities

• ..internal design tools?

This became the leading question for the interviews made for creating the needs analysis. The format
of the interviews was to identify a problem and a possible way of solving it through an activity. Seven
internal interviews with different backgrounds were conducted to receive differentiated opinions
and ideas on the topic. In addition, two external interviews with LTU Green Fuels were made to
achieve a perspective more related to research and development from academia.

Information from the interviews was compiled into a diagram outlining the status of each possible
activity, connection to parties and relations to other activities. This diagram could be described as
the observed needs analysis, which could be used in the next step of bench-marking suggested topics.

The bench-marking was made with the main criteria of relating a possible activity to the technical
standpoint of making the topic relevant to the academic side of the thesis. Then, the selection was
made with the supervisors and external parties, and the next step to the first Descriptive Study
could be made.

3.1.2 Descriptive Study I (DS-I)

Taking the chosen topic into the stage of investigating further as empirical analysis, the first task
was to identify the success factors of what the topic should fulfil and why they should be addressed.
This evaluation was also conducted from the interviews as a result of questions of how specific
activities can answer the leading question. Finally, one practical analysis was made to identify the

12
existing solution’s capabilities and understand how a potential solution can enhance the delivered
results.

After investigating possible solutions through articles, reports and interviews, an insight occurred
when the industrial standard for the chosen topic became the limiting factor. Knowing this early, the
first distinction of primary aiming for an internal solution was made to enable either a non-industry
standard solution or a combination.

3.1.3 Prescriptive Study (PS)

The first iteration of the chosen activity was made by gathering multiple sheets of technical
specifications into a general collection, focusing on an aligned format between technologies for
further comparison. Continuous briefing sessions with the technology department made it clear
that the activity had to increase to a comprehensive approach to address the earlier defined
factors. Therefore, an additional three work packages were considered to answer each factor. After
discussions with the construction team, the Plant Breakdown Structure (PBS) became the
first work package to seek a combination between different industry standards, as earlier mentioned
as the limiting factor. The already established PBS had extensive capabilities for the specific plant
and equipment, but the decision to further advance into flows and streams was made with support
from the construction department. After the philosophy of the structure had been made, +1000
requirements in the collection of specifications used the PBS.

Simultaneously to the PBS, concerns regarding the accessibility of the data were raised. The
concern surrounded how a user will work with the requirements and how to identify a specific
flow to a component. A new work package was formed focusing on creating a flow diagram that
includes components for each technology, outlining shared components and including the PBS for
identification. By taking inspiration from the existing flow diagrams, a combination had to be
made again to suit the use case. Identified standards of flow diagrams either had too complex
information or neglected essential metrics for the proposed workflow.

After the collection of requirements, the PBS and Flow diagram was finalised, an evaluation was
made investigating the compatibility of these three and how they answered to the initial scenario
as a model. Working in the PS stage, one proposed output is to have general requirements for how
the proposed model will work. At this stage, the proposed work had a solution to the scenario
but required a static scenario. A dynamic approach was discussed internally, discussing how the
dynamic approach could be obtained. Thus, given the few sample size of the cost estimations,
would a dynamic approach to modularisation be valid? After researching existing modules of the
systems, the understanding was that building a configurator based on the existing modules could
be done. The third work package was then created to increase the compatibility of the finalised
database by using modularisation. The earlier researched modules were assigned as parameters to
answer to specific production volumes and attributes. The main focus was to build the underlying
logic and formulas on the structure. A proof of concept user interface was created in Excel to
demonstrate the capabilities for the presentation and illustration aspects.

13
3.1.4 Descriptive Study II (DS-II)
The last phase of the DRM began with understanding how and why the database answered the
factors that were supposed to be addressed. As the DRM methodology suggests, this was already
initiated in the PS stage when evaluating the current capabilities and expanding the model to a
database. The capabilities could be determined by asking practical scenarios and presenting the
database to departments of interest. Questions of whether a person can see a practical use of the
database in a scenario and how? The responses were linked to the initial factors stated in the
DS-I and reviewed. Finally, a conclusion were posed from the discussions with the result that the
database met the factors.

While reviewing the addressed factors, future work and implementation became a highly related
topic. This is due to the extension of the previous discussions if a modularisation is possible,
whereas new topics surrounded module optimisation. For module optimisation, an approach looking
at a dynamic load was initiated. This began with distinguishing components with load range
respectively fixed load. At first, the topic was meant to be included in the configurator until
the complex optimisation became a limiting factor. Therefore, this became a future work topic
handed over for the following cost estimator’s next iteration. Then, the focus shifted to ensure that
responsible departments first understood the logic of the modules. The same applied to the logic
of the PBS, hence the magnitude of implementation and the broader area of interest, beyond the
handed-over database.

14
4 Results
The thesis results are presented in two sections, and the first section presents the outcome from the
support methodology for the process development. Then, the results from the database are shown
in the second section.

4.1 Design research methodology

This section presents the results using the theoretical framework from Section 2.1.

Research classification
The initial thesis proposal suggested four work packages considered as mission statements for the
project. They followed as follows;
1. Design base for OEMs
Mapping technical data and viable parameters needed to proceed and fulfil a requirement
specification is an approach of an extended enterprise. Therefore, this segment requires
contact with OEMs applicable for H2GS’s operations.
2. Design tools for the site
Deploy data from OEMs as a standard for design tools used by H2GS to design production
installations for facilities. Underlying mapping of compatibility and requirements of the
design tools.
3. Technical databases for geographical position
Outline systematically external parameters that influence the RFx technically. Mapping
boundary conditions to be associative for activities within the design tool, e.g. specific
location’s water quality, leads to filtering requirements for OEMs.
4. Implementation
Technical implementation in a front-end environment, integrated into the design tool. In an
implemented phase, an initial RFI generates once an activity has been finalised in the design
tool. For example, an activity could be considered an assembly of a furnace. The generated
RFI includes specific OEM requirements and the geolocation aspects and actions.

Needs analysis
Due to the rapid expansion of H2GS’s operations, the four work packages were redefined after the
project’s initiation. After nine interviews with employees in the technology department, a needs
analysis could be defined for the project. This is illustrated in Figure 8 whereas the rows represent
the stage of action. The rows follow as:

Actions made
• RFI
H2GS have an established procedure for RFI communication with customers
• CAPEX and Cost estimator
H2GS have an established cost estimator for building a quotation for a hydrogen plant

15
Stakeholders
• Customer
Buyer of a hydrogen production plant or internal processes of procurement
• H2 Green Steel
H2GS acts as a middleman in the value chain, providing a viable solution for hydrogen
production
• Electrolyser OEM
Develops and manufactures an Electrolyser and/or sub-systems

Undefined
• Cost estimator-updater The identified demand for developing a sub-system to update cost
variables based on a linear regression approach, including continuous updates of cost figures
• Process description The identified demand is to map the standard process for requesting
information and quotations from customers and OEMs. This also subjects as process
description of a hydrogen plant in terms of understanding each components connection
• Sourcing strategy The identified demand is to clarify a structure of the internal criteria
how a supplier is chosen in terms of technical performance and what shall be outsourced to
external parties
• Requirements The identified demand for building a database for the OEM’s specific
requirements

Figure 8: Observed Needs analysis for H2GS. Actions made contain activities discovered in
interviews with employees. Stakeholders, where H2GS acts as a middleman between the customer
and supplier. Undefined outlines the identified needs where no action has been taken.

16
Descriptive Study I (DS-I)
Working with the outcome from the needs analysis in Figure 8, the most demanding undefined
activity was the Requirements. [9]

How are system requirements addressed today?

Due to the current design dimensioning phase of the company, seen as a project, mapping the
technical requirements from suppliers is not considered a crucial parameter. Hence, the H2GS
current phase is scoped linearly to a specific plant(s); the thesis has its approach defined to other
potential plants simultaneously. The current process capabilities could be exemplified in a scenario
where a potential customer approach H2GS with a request for local hydrogen production at the
site. The response will primarily focus on equipment configuration and financial figures, neglecting
parameters such as available intake streams or facilities. A time-consuming process will occur if
such aspects are considered to be able to, for instance, shave capital expenditures due to existing
equipment.

Which factors should be addressed?

Technical Data collection
Due to the varying electrolysis techniques, each technique inherits its design base, ultimately
unable to compare. Therefore, a valid comparison should be judged specific to each site. To
enable the comparison, a distinction between modular and interface requirements is desired.
It is also a crucial factor to configure the requirements into a scalable matter in terms of
accessibility, compatibility and reliability. Regarding accessibility, it came into understanding that
an illustrational map of a combined system outlining components graphically and shared ones
should be addressed. Furthermore, considering the compatibility, an applicable standard in terms
of a tagging strategy has to be considered. [9]

Prescriptive Study (PS)

The thesis work packages are summarised in figure Figure 11. Here are the packages divided into
three main parts, whereas the Plant Breakdown Structure (PBS) acts as a sub-package for the
requirements database based on Excel.

Figure 9: Workpackages for the thesis

17
How are factors addressed in thesis work?
The following section answers the factors stated in Section 4.1 in an extensive matter, related to
the work packages shown in Figure 11.

Modular requirements
These are the requirements for feeds and streams connected/to the electrolyser, which scales
with the production rate. With the requirements, this was a vital aspect while configuring the
production rate to modules. Stream parameters of water and Nitrogen are, for instance, necessary
while speaking of capacity and flow.

Interface requirements
The interface requirements are subject to the fixed requirements, such as available flows and
pre-installed grid connection. These are the requirements determining the selection of actions that
OEM must consider. If, for instance, the functional capacity of Nitrogen is in the range of the
amount of production - this can already be determined before sending the RFQ to the OEM.

Configurator requirements
Derived from the determined modules in Section 4.1, the configurator applied to each supplier
will take the desired production rate as input and deliver the demanded substreams and outputs.
This is possible through interlinking the modular and interface requirements together. Further,
an additional layer of financial data to each process equipment can be included hence the level of
specific granularity generated through the equipment list.

Compatibility and reliability

When approaching the integration step between the database and the visual flow diagrams, the
understanding came quickly that a referring system must be considered. This also secures future
database integration with a universal approach to tagging streams. This is a way of distinguishing
assigned streams to a reference in the database and vice versa. To fulfil the commitment by
developing a forward-compatible solution, the system also has to align with the general approach of
identifying components. The conventional process in the procurement industry is by using a PBS,
discussed earlier in Section 2.5. The first draft was introduced during the thesis for the Boden site,
whereas this could be used as a template for the integration. To use the PBS as a template, the
hierarchy of a stream had to be determined. The breakdown is illustrated in Figure 10.

18
 Figure 10: Breakdown of a stream connected to a component

This breakdown was reviewed together with recommendations from an engineering consultant firm.
The approach is derived from the attribute information. This means that the stream is assigned on
a top level to a component, not from the stream itself. Starting with the component, the quality
can then be determined. This requirement is often unique to its application and includes qualities
such as purity and composition. Conditions and pressure have also been chosen in this level hence
the non-varying dependencies. This is followed by consumption, which includes three central units
to describe volume- normal volume- and mass flow. To determine the time dependencies for the
volume flow, the database also describes the behaviour of the flow as continuous or intermittent.
Components demanding continuous streams, such as electrolysis consuming lye constant in an
active state. Intermittent consumption in the same system is applied when purging the system
with Nitrogen. Since quantity is the integration of consumption over time, this follows by quantity.
By considering Nitrogen purging again, there is often a requirement for available capacity - rather
than the time of consumption. By taking the established PBS into account, the stream of Nitrogen
could be coded in such a way illustrated in Figure 13 in the database result.

In terms of the reliability of the database, the crucial factor is to have the database updated
with information that is true to date. A re-calculated model or shortages in material results in
re-evaluation, leading to requirements changes. Given that the flow diagrams are independent of
changes in requirements rather than dependent on changes in the equipment, it’s time-consuming to
update the changes. Furthermore, the objective of the flow diagrams is to illustrate rather than use
them as a basis for construction. Therefore it became more relevant to address how the requirements
in the database are supposed to be updated in a consequent methodology. The philosophy that
has been in use is to gather information transparent outlining sources, the publishing date of
requirement and section of the article. This is the proposed methodology for future implementation
for embracing reliable data.

Accessibility
The Needs analysis found in Figure 8 conducted several undefined activities, such as Requirements
and Process Description. Namely, the last activity could be confirmed to be demanded in discussions
with several departments, both in terms of educational and system purposes. In developing a flow
diagram for an educational purpose, the key driver is to deliver information to support competence
within the system independently. From the perspective of the system purpose, the flow diagrams
could support integration in a multi-layer system model. These factors were considered while

19
choosing what industry standard to determine and which technical level the final diagram shall be
designed to act within.

Given from Section 2.3, the processes for developing the two different diagrams differ in terms of
purpose and technical inclusion. This became an aspect to take a stance; Shall the shared flow
diagram act as a basis of a PFD or a more comprehensive P&ID? A distinction could be made
where the PFD is intended for a high-level approach, which is suitable for the educational purposes.
On a side note, this high-level approach wouldn’t include streams necessary for interlinking with the
requirements database. On the other side of the spectra, developing an industry-standard P&ID
was not possible hence the state of engineering. A diagram of such demand site-specific information
is determined in a later stage of engineering and is therefore irrelevant to the scope of the thesis.
The developed flow diagram was based on provided PFDs and P&IDs from each specific supplier,
where technical specifications distinguished each component that was either optional, shared or
included in the particular scope. This could be implemented both graphically and further on in the
requirements database.

4.1.1 Descriptive Study II (DS-II)

The thesis work packages are summarised in figure Figure 11. Here are the packages divided into
three main parts, whereas the Plant Breakdown Structure (PBS) acts as a sub-package for the
requirements database based on Excel.

Figure 11: Workpackages for the thesis

Comparison with existing processes

In favour of having a way of adjusting the requirements in a dynamic configurator in accordance
with desired production volume gives incentives for early dimensioning. Earlier linearly scaled cost
estimations can be eliminated hence specific module ranges. This enables the estimation to include
a discrete cost model, ultimately enhancing confidence for a first-step quotation.

Building a platform for this information, in this thesis named Requirements Database, also contributes
to enhancing the cost estimation through existing interfaces. Earlier elaborated in Interface
requirements, benefits such as understanding what interfaces shouldn’t be taken into consideration.

20
Factors to compare
Requirements
As described earlier Descriptive Study I (DS-I), the current solution for requirements neglects the
distinction between modular and interface requirements by only taking a linear scaling approach.
This had to be a manual process to answer potential customers’ existing interfaces. The requirements
database enables gathering and delivering this information in an efficient matter.

Accessibility
In the Figure 8, the undefined activity process description was a highly observed activity. This
subject to documenting and developing a chronological process of the RFx communication with
suppliers and customers. In extension, this could also be an extension for a technical description
of the processes within the hydrogen production for educational purposes. Furthermore, a low
threshold is amplified by having the requirements and flow diagrams interlinked to the components.

Compatibility
The standardisation resulting from a plant breakdown structure enables compatibility advantages
across several processes internally and for the implementation of this thesis work. The earlier
approach was limited to using technical specifications as reference rather than using a specific code
for each assigned requirement, which is possible now. The database can be implemented into an
extensive system with a reduced formatting focus with particular coding.

Reliability
Observations during the needs analysis indicated that multiple projects within H2GS on comparing
suppliers have varying reliability in terms of the source of information. This variety is founded on
different stages of engineering, which ultimately cause misinformation. When data is imported into
the database, it comes with input classifications. For example, one classification is to state the
information document name and publishing date. This gives opportunities to extrapolate further
if data is expressed as new or old to the comparison, which can also be a factor in determining
technical specifications for a supplier in general. The benefits which also embrace reliability are
that the requirements database emphasises the one bank of knowledge, acting as the primary
source of information - having control of which information is used within, for instance, projects of
comparisons.

4.2 Database
In this section, the results of the work packages are presented together with a practical scenario of
usage. The work packages are found in Figure 11.

4.2.1 Requirements
The specific database for requirements can be found with an example in Figure 12. The stream
of interest here is the outgoing hydrogen flow from an electrolyser with its related conditions in
terms of quality, consumption and quantity. The name tagging strategy is also included for sets of

21
a range with the logic further described in Section 4.2.1. Finally, the format is also aligned between
metrics for different technologies for a valid comparison.

Figure 12: List of requirements for outlet flow, including boundary conditions and item coding

Compatibility
One criterion to consider was forward compatibility. Therefore, each requirement must be assigned
with the internal procedure of tagging strategy. A tagging strategy is conducted through a Plant
breakdown structure (PBS), including a layer-based structure for a planned site. Taking the
established PBS shown in Figure 10 into account, the hydrogen stream could be coded in such a
way illustrated in Figure 13. The philosophy of the breakdown could be described as attributes
derived top-down from specific equipment. Therefore, the already established PBS applies for
the equipment and the stream’s medium are connected, in this case, the tag PEM.HDM and
H2G, creating PEM.HDM.H2G. Finally followed by the attributes, quality QLT1, consumption
CONS1 and quantity QTY1, sums up to PEM.HDM.H2G.QLT1.CONS1.QTY1.O.NOM.
The last two attributes indicates the direction of the flow, in (I) and out (O) and the rate ranging
from minimum (MIN), nominal (NOM) and maximum (MAX).

Figure 13: Breakdown of produced hydrogen from an electrolyser

4.2.2 Configurator
The configurator to the database enables requirements that apply to streams to be summarised
for further evaluation. Evaluation by enhancing estimates that are time-consuming calculations
for each requirement to be automated. The philosophy of the configurator is to adjust the desired
production volume to the OEM’s specific modularisation, which contributes to realistic measures

22
in the consumption figures. This also enables the outlining number of equipment per the minor
possible configuration.

The configurator is shown in Figure 14, with two inputs delivering 22 outputs. As shown in the
specified parameters highlighted in yellow, the production volume is adjusted to the product’s
production volume under modules, as described above. Highlighted in orange are the defined
modules for stacks, groups and halls, which are subjected to change depending on supplier updates.
One stack represents several Electrolysis cells merged, often a co-axial design in an Alkaline module.
A group consisting of several Electrolyser stacks, designed to support the ability of scale and fit to
sub-components. A number of groups form the module production hall to respond for a sense of
footprint. The configurator can be found with a larger resolution in Section 7. Highlighted in green
are the following:

• Configuration details
Number of modules for the configuration

• Power
Demanded Power supply for the configuration

• Consumption figures
Demanded figures for flows or quantity of critical streams

• Effluents
Streams of effluents that either are recycled or considered waste

• Footprint
Different measures of plant footprint as a function of production halls, power and production
rate

• No. of equipment
The list of equipment aligned with Figure 16, including the corresponding units per module

Figure 14: Configurator mockup with arbitrarily numbers

23
By judging the result from Figure 14, the desired production volume is not ideal for building an even
production hall by the module with the specific model. In such a way, this configurator is not meant
to replace nor automate the dimensioning aspect of procurement, which ultimately can deliver
a production hall meant for 17 groups. Instead, these results can be evaluated for optimising modules.

The logic of the configurator is illustrated in Figure 15. First, the configurator starts comparing
the production volume as an input parameter with the specific module size, hence the module size
is based on the technical specifications. If the production volume is not evenly divided with the
modules, the input is rounded to the nearest possible production rate. With the modularisation,
the technical conditions can now be imported from Requirements. Starting with the quality
boundary conditions, which emphasise the fixed quality requirements. This follows with the variable
requirements corresponding to production volume. Finally, the design base for an electrolyser
system is compiled, which also is shown in Figure 14.

Figure 15: Logic of the configurator expressed as a flowchart

4.2.3 Flow diagrams

Figure 16 shows the logic for the combined diagrams is presented. The logic is described earlier
as a methodology to identify specific requirements for streams and components. The illustrated
flow diagram consists of three categories, two different techniques of electrolysis and their shared
components in one section. A table of the plant breakdown structure is linked with numbering
symbols in the connecting flows in each section representing the techniques. For demonstration,

24
the stream 7, located at the most left section of supplier PEM, connects the H2 demister to the
shared compressor. The unique number can also be found in the table of codes in the top left
corner, inheriting the code; PEM.HDM.H2G.QLT1.CONS1.QTY1.O containing attributes
for the stream of hydrogen. The specific codes philosophy and usage are earlier elaborated in
Compatibility.

Figure 16: The resulted Flow Diagram. Components and processes imported from [Guo].

4.2.4 Usage of the database

The philosophy of having a flow diagram formatted to a database is based on practical usage from
both sides. Intuitiveness increases when requirements are assigned to a specific flow, outlined in a
flow diagram. Described in Section 4.1. Taking the example further, described in Section 4.2.3,
the specific flow’s boundary conditions can be found in the requirements data set. The Figure 12
include information for the stream connecting the H2 Demister to the shared compressor.

25
5 Discussion
For the conditions for process engineering of the thesis, the following chapter will elaborate on
the methodology of the generative idea phase and the deliverables capabilities and limitations.
Hence the thesis results are directly related to the concept of answering undefined activities.
Therefore, compared with evaluating a current process, the database’s usability can be confirmed
after integration.

5.1 Work Methodology

Earlier discussed in Research Classification found in Section 3.1.1, the first step of Design Research
Methodology, was an iterative process of investigating undefined activities and factors to address.
This process consisted of generating theses to confirm or deny, which could lead to activity. As stated
in the Section 2.1.1, the output of the stage shall include a general understanding and expectations
of the supposed work and a general research plan. Hence the rapid emerging environment, as
mentioned in Section 3.1.1, this became a blocker in the initial start of the thesis. The Research
Classification stage should have been initiated earlier in this project with more documentation
and literature for working in the DRM environment. The phase of defining criteria, in this
context as factors, should have been considered after finishing literature and research, rather than
simultaneously. The needs analysis would have been generated with prior knowledge, and the
interviews could have been conducted comprehensively.
The intended formats were designed for the flow diagram in the prescriptive study. By taking
the making for the requirements list as a reference, defining the formatting came to be the initial
step before importing the specific information. This act of pre-conditioning the requirements
for the potential outcome became a successful parameter for comparing the suppliers hence the
different terminology and units. To the extent, this methodology should have been considered while
developing the flow diagrams. Comparing the format for the flow diagram and the requirements, it
became unique for a standard from one supplier, Supplier A.Supplier B’s components were
therefore formatted to the Supplier A’s standard. For example, components inheriting the Balance
of Plant or/and Electrolyser System differ from Supplier A to Supplier B, which could result in
terminology changes such as in power distribution for Rectifier and Transformers instead of Power
supply. This could have been avoided if the same requirements methodology had been implemented.

5.2 Deliverables
Outcome
Starting with evaluating the addressed factors, concluded in Section 6.1, the reference for stating
these factors were interviews with employees. Summarised from the interviews could generate the
factors, followed by a needs analysis. One objection could be raised if the discussions were framed
to personal experience rather than the organisation’s current stage. However, indications point out
that the earlier defined factors are still relevant to how the deliverables will be used in the company.
[9]

Limitations of the database

The database’s current limitations are highly bound to be updated once a new engineering study
has been conducted. Hence the maturity of the Electrolysers is still in development; some systems

26
are still under development after a commitment has been set between customer and supplier for a
specific installation. Therefore it’s necessary to point out that varying confidence for the database
occurs, and manual updating must be considered.

27
6 Conclusions
6.1 Addressed factors
Before starting the thesis work, a scope including several work packages had been identified. Earlier
elaborated in the Section 3, this became rapidly revised due to outdated outcomes. The Needs
Analysis described in Figure 8 indicated the four undefined activities: CPQ-Updater, Process
description, Sourcing Strategy and Requirements. Here, the main chosen activity for the thesis
became Requirements and building its database. It came to the understanding that despite mainly
focusing on building a database for requirements, synergies of how the result was presented could
be found with the other listed activities and factors. These additional factors could be described as
accessibility, compatibility and reliability, as earlier stated in Section 3.1.2. These are both related
to the database as a direct consideration of how the requirements are handled and additional work
packages that came into impact for applications with no direct linking to the requirements.

By considering the factors described above, this resulted in additional work packages exemplified in
Compatibility, Flow diagrams, Configurator. The specific work packages answer to the factors are
summarised in Section 6.1, mapping the contribution.

Table 1: Workpackages to address factors - Low/Medium/High Contribution

Work package Accessibility Compatibility Reliability

Requirements Contribution - Contribution
Plant breakdown structure - Contribution Contribution
Configurator - Contribution Contribution
Flow diagram Contribution - -

Regarding the requirements, it became an essential contribution to accessibility; the information is

gathered in one data set. By delivering this, an extension of reliability is obtained. Thus, using one
channel for information can reduce contradictory numbers. Looking at Plant Breakdown Structure,
the contribution for compatibility is mainly addressed. This enables the database to be connected
to more information streams internally in H2GS, hence the same identification system for process
equipment. However, this means that the plant breakdown structure’s invented part must be well
defined and documented for further implementation.

The configurator has its purpose in mainly building a proof of concept for how modules correspond
to different streams and equipment, with not being the defined model of usage - instead, an
investigation of how this could be built in the optimisation tool. Therefore the main contribution is
to compatibility aspects of later implementation, followed by reliability. In terms of reliability, this
gives essence to the element of looking into a sophisticated approach of scaling, earlier described
as the Discrete scaling. Enhancing the scaling supports the financial approximation, ultimately
delivering a more reliable cost model.

The compiled flow diagrams fulfil the purpose of pedagogical independence, which is considered a
valuable tool in the emerging growth internally within the company in terms of general knowledge

28
of an electrolyser system. Furthermore, the format is aligned with the plant breakdown structure,
which unites the format with the requirements list, giving a graphical representation for each
stream. This contributes to the general factor of accessibility; hence, it supports general and specific
knowledge.

Finally, based on the summary above, the thesis contributes to the initial request for a hydrogen
production plant recommendation.

29
7 Future work and implementation
For future work, compatibility is one key driver to continue with hence the interlinking attribute
for the proposed methodology described in Section 4.2.2 and Section 4.2.3. In future operations
internally, tagging a stream before engineering studies have to be made per Figure 13. The PBS
extension does not have full coverage for all suppliers in the handed-over thesis material. This
results from not having the initial standard for the equipment done for several different Electrolyser
techniques. For the stage of handing over the thesis work, the framework for the tagging strategy
is the main objective, found in Figure 13. Understanding the philosophy is the crucial factor for
integration, and the responsible technology department will first evaluate the proposal to integrate
into the internal design tools.

A multi-layer system model is desired to achieve a more detailed flow diagram, including connecting
the up-and downstream components. The result to date includes a simplified flow in a short circuit
design. This has potential for usage in a simplified matter but should not be taken as the direct
source of information. In use internally, this directs firstly to onboarding processes but as described
as one of the main advantages for the sake of the thesis is the connection to the database of
requirements.

Given the result from the thesis configurator, the next iteration of the already existing cost estimator
will mainly focus on implementing the philosophy of modules, streams, equipment and requirements.
In the existing format, discussions with the development team have taken place with a clear sight
of how it will be integrated in terms of logic and indicators. Hence the interface built in the thesis,
shown in Section 4.2.2, is a proof of the concept of modularisation rather than an end-product, the
information to enable the next iterations are the modules and logic. This configurator is therefore
handed over with a granular description of how the modules were sourced and how they are linked
with the production volume. For future work, one aspect that demands engineering details is the
dynamic load range for each piece of equipment. For example, in the configurator equipment list
shown in Figure 14, the number of compressors as needed is 5,3. Hence this is not an integer;
this opens up a dilemma. Are the needed compressors five or six, taking the specific compressor’s
dynamic range into account. For context, does the compressor have the ability to overcharge
to decrease the CAPEX and increase the OPEX, hence the non-recommended operational load?
To cover this, further data is needed to understand the combination of the safety factor and the
accepted load range.

Finally, to provide a well-specified RFQ for the supplier - the format of the output from the finalised
cost estimator has to be in a comprehensive state of including the RFI input compared to the
requirements and the specific site’s equipment list and the calculated dependencies. Professional
procurement processes shall be well considered in software and tools for buyers to further work
on this topic. Therefore, the design and process for conducting these weren’t considered for the
framework for the thesis. Instead, the backbone of the technical aspects acted as the main synopsis.

30
References
[1] MR Irena. IRENA Hydrogen numbers. Accessed on 2022-03-18. Mar. 2022. url: https :
//www.irena.org/.
[2] Amaresh Chakrabarti PhD Lucienne T.M. Blessing PhD. DRM, a Design Research Methodology.
Springer Dordrecht Heidelberg London New York, 2009. Chap. 2.2, p. 15.
[3] Homam Nikpey Somehsaraei Abhinav Bhaskar Mohsen Assadi. “Decarbonization of the Iron
and Steel Industry with Direct Reduction of Iron Ore with Green Hydrogen”. In: Energies 13.3
(2020). doi: https://doi.org/10.3390/en13030758.
[4] H2 Green Steel. Producing green steel in a fully integrated, digitalized and automated greenfield
steel plant. Accessed on 2022-05-19. url: https : / / www . h2greensteel . com / producing -
green - steel - in - a - fully - integrated - digitalised - and - automated - greenfield -
steel-plant.
[5] Sean Moran. Plant Layout. Joe Hayton, 2017. Chap. 2.5, pp. 16–17.
[6] MARGARET JAMES. Request for Proposal (RFP). Accessed on 2022-04-08. May 2021. url:
https://www.investopedia.com/terms/r/request-for-proposal.asp.
[7] Michael Tupek. Request for Bid Vs. Request for Proposal. Accessed on 2022-05-17. July 2021.
url: https://scionanalytics.com/request-for-bid-vs-request-for-proposal/.
[8] Hexu Liu Maha Al-Kasasbeh Osama Abudayyeh. “An integrated decision support system for
building asset management based on BIM and Work Breakdown Structure”. In: Journal of
Building Engineering 34 (2020), p. 4. doi: https://doi.org/10.1016/j.jobe.2020.101959.
[9] H2 Green Steel. Private discussions with employees. Axel Lindwall, 2022.

31
Appendix 1 - Configurator

1
Figure 17: Configurator mockup with arbitrary numbers