Available online at www.sciencedirect.

com

ScienceDirect
Procedia CIRP 119 (2023) 656–661

33rd CIRP Design Conference

A Living Lab Platform for Testing Additive Manufacturing Agent-Based

Manufacturing Strategies
Lorenzo Giuntaa,, Ben Hicksa , Chris Snidera , James Gopsilla,b
a School of Civil, Aerospace and Mechanical Engineering, University of Bristol, UK
b Centre for Modelling and Simulation, UK

* Corresponding author. E-mail address: l.giunta@bristol.ac.uk

Abstract
Distributed manufacturing systems are seeing increased investment by manufacturers looking for a more responsive, robust, and sustainable means
to meet product demand amid market fragility, mass-customisation, sustainability, supply chain uncertainty, national security, Net Zero and the
Circular Economy. One such system is Additive Manufacturing farms where numerous machines are housed in warehouses across the globe. The
realisation of these systems in industry is offering the opportunity to exploit research in agent-based manufacturing strategies for the brokering and
coordination of jobs. Until now, much of the underpinning research has been numerical and validation via empirical study is required to provide
confidence in deploying the strategies in an industrial setting. To provide this validation, this paper presents an Opensource Living Lab platform
that can be used to evaluate agent-based manufacturing strategies.
© 2023 The Authors. Published by Elsevier B.V.
This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0)
Peer review under the responsibility of the scientific committee of the 33rd CIRP Design Conference

Keywords: Distributed Manufacturing; Agent-Based Manufacturing; Living Lab; Validation

1. Introduction clude: Additive Manufacturing, robotics, automated inventory,

closed-box Computer Numerical Control (CNC), the Internet-
Manufacturing and Supply Chains are experiencing unprece- of-Things (IoT), networking, cloud infrastructures and man-
dented change [10]. Changes in societal behaviour, such as ufacturing resource planning software systems. Combined, it
the ‘Maker’ movement, mass-customisation, and the desire for enables a readily deployable flexible manufacturing capability
rapid delivery require an on-demand and responsive manufac- within standard warehouse infrastructure. Demand is then dis-
turing capability. Net Zero and the Circular Economy have de- tributed amongst the many machines housed in the system.
veloped an existential crisis in how society should manufacture Unlike conventional production, flexible distributed manu-
and supply itself [3]. Market fragility and supply chain uncer- facturing systems afford [1, 16, 7]:
tainty is increasing the risk in forecasts, resulting in smaller and
more intermittent orders being made. National Security agen-
das are encouraging the re-shoring of manufacturing and an in- 1. Reduction in distribution costs.
crease in global ‘shock’ events, such as COVID-19 and the war 2. Shorter lead times.
in Ukraine, are requiring more resilient manufacturing and sup- 3. Less capital investment.
ply chain architectures to be developed [18]. 4. More flexibility in capacity.
In light of these events, manufacturers have been increas- 5. Better capacity utilization
ing investment in the study and deployment of flexible dis- 6. Larger pool of experts.
tributed manufacturing systems brought about by a combination 7. Diffusion of risk.
of digital-physical manufacturing innovation. Innovations in- 8. Boost to local economies.
9. Sustainability.
✩ This document is the result of research funded by the United Kingdom’s En-

gineering and Physical Sciences Research (EPSRC) Council – EP/R032696/1, Additive Manufacturing (AM) is one of the manufacturing
EP/W024152/1 and EP/V05113X/1. processes driving Flexible Distributed Manufacturing Systems.
It affords the ability to rapidly change between component man-

2212-8271 © 2023 The Authors. Published by Elsevier B.V.

This is an open access article under the CC BY-NC-ND license (https://creativecommons.org/licenses/by-nc-nd/4.0)
Peer review under the responsibility of the scientific committee of the 33rd CIRP Design Conference
10.1016/j.procir.2023.03.118
 Lorenzo Giunta et al. / Procedia CIRP 119 (2023) 656–661
ufacture with little to no re-configuration and/or changeover
time [6]. It can also be readily deployed in a range of loca-
tions from homes, schools, universities, offices and standard
warehouse infrastructure. For example, there are an estimated
168,000–230,000 3D printers in the United Kingdom [19, 20]
resulting in a combined manufacturing capability that could
produce 2.02–2.76 Million Lateral Flow Devices per day 1 .
The challenge for manufacturers wishing to unite and oper-
ate a Flexible Distributed Manufacturing System is the broker-
ing and coordination of work. The systems must react to con-
tinually changing and unpredictable demand profiles that need
to be distributed amongst the numerous machines within the
system. Machines may be in different locations and operated
by different organisations, with differing requirements and con-
straints (e.g. availability of certain materials). This limits the ap-
plicability of typical top-down production control methodolo-
gies [9]. In these cases, Agent-Based Manufacturing strategies
have been identified as a suitable solution. Agent-Based Man-
ufacturing represents machines and jobs as agents. The agents
feature the necessary information to represent a particular ele-
ment of the system and operate autonomously communicating
with other agents. Through their communications, work is co-
ordinated and distributed. Agent-based systems increase flexi-
bility and responsiveness due to the agents’ independence, al-
lowing for the parallelization of decisions and real-time adjust-
ments [15, 5].
However, many of the advantages have only been evidenced
through numerical modelling due, in part, to the lack of real-
world capability to realise such systems. As is often the case
with numerical modelling, they feature assumptions of ide-
alised conditions and do not necessarily concern themselves
with the practical challenges of implementing their communi-
cation strategy in a real-world setting. Example challenges in-
clude the consistency of operators in maintaining system oper-
ations, robustness of the machines in operation, and the will-
ingness to share information between agents. It is argued that a
empirical studies through real-world implementations is a con-
tributing factor to the lack of adoption.
To fill this gap, this paper details an Opensource Living
Lab (LL) platform to support the field in testing and evaluat-
ing Agent-Based Manufacturing strategies and thus help move
the technology along the Technology Readiness Levels (TRLs).
The paper continues with a review of Agent Based Manufac-
turing System (ABMS) research where the requirements for a
platform are elicited (Section 2). This is followed by a descrip-
tion of the platform’s architecture (Section 3). A demonstra-
tion of the platform with a published communication strategy
is presented and comparison between real-world and simulated
results made (Section 5). A discussion then details the insights
that can be generated through studies using a LL (Section 6).
The paper then concludes with the key contributions of the work
(Section 7).
1 2hrs printing time per device [17].
657
2. Requirements for a Living Lab to test Additive Manu-
facturing Agent-Based Manufacturing System concepts.
When considering the type of infrastructure to utilize for
the development of the LL, a number of architectures were
considered. PROSA, FABMAS, and ADACOR, architectures
are based on the Multi Agent Systems (MAS) holons concept
[22, 14, 8, 4]. Holon, is derived from the Greek “holos” (whole)
and the suffix “-on” to indicate a particle or subset [21]. As
hinted at by the name holons are used to describe systems that,
due to their complexity, are built of increasingly small sub-
assemblies which remain fully functional microcosms. This du-
ality is how holons can be seen as wholes which exist due to
smaller parts but also as interconnected and inter-operable as-
semblies. While not strictly hierarchical, holons tend to favour
hierarchical orders to ensure the interoperability of the system,
as smaller assemblies must fit within larger ones [4]. Thus the
models (PROSA, FABMAS, and ADACOR) maintain a form
of hierarchy which is inherent to the holon philosophy.
As the network that the LL aims to replicate and test is one
based on leveraging makers and disparate manufacturers, it is
hard to create a hierarchical structure to ensure coordination.
This is particularly true for individual makers and outfits run-
ning just one or a few AM machines. In such a scenario, where
there is low organisation across holons, MAS begin to more
closely mimic the behaviour found in heterarchical systems,
as the holon consists of a single AM machine [2]. Anarchic
systems are a form of heterarchical production control systems
[12], but their interaction is based on an open market approach.
As with heterarchical systems, the control and governance is
maintained at the agent-level. However, agents within anarchic
systems are in a continuous state of competition as they bid for
work, mimicking the interactions found in stock markets, and
collaboration is obtained despite each agent working primarily
for its own self interest [11, 13].
While desirable to have such an approach for the final im-
plementation of the ABMS for AM, the added requirement for
the LL is to allow for data collection and an overview of the be-
haviour of the agents in the LL. Challenges in these systems is
how the local control and governance can be configured in such
a manner to provide the desired emergent system performance.
Implementing and studying these systems requires fine-grained
monitoring of the communications between agents in order to
draw correlations between agent configurations and system be-
haviour.
As such, the architecture selected for the LL is inspired by
both the ADACOR and anarchic architectures. From ADA-
COR, the proposed LL architecture borrows both the use of
separate holons connecting into a network infrastructure and
the use of a virtual resource to represent the physical manufac-
turing resources available (AM machines) which is necessary as
the machines in question are not designed to connect to such a
network and take jobs independently [8]. However, in line with
the flat hierarchies proposed by anarchic manufacturing [12] the
LL’s architecture eschews ADACOR’s hierarchical setup, pre-
ferring a flat organisation for both machine and job agents, with
658 Lorenzo Giunta et al. / Procedia CIRP 119 (2023) 656–661
the network infrastructure acting merely as a passthrough con-
necting the machines to the jobs. This central passthrough point
allows for an overview of the network to be maintained, which
would be complex if not impossible if all the communication
between agents occurred in a distributed manner, as proposed
by fully anarchic systems. This allows for data collection and
network monitoring, favouring the LL’s ability to gain informa-
tion on how various experimental parameters impact the output
and behaviour of the overall manufacturing system, allowing
for comparison to computational models. For example, it would
be possible to explore how different protocols for job selection
by the virtual resources impact the number of jobs manufac-
tured and the time each job waits before being accepted.
3. A Living Lab for AM ABMS
Fig. 1 illustrates the template for the AM ABMS discussed
in the previous section. This template formed the basis of the
design of the Living Lab’s architecture. The four components
highlighted therein were:
1. Broker service (Network Infrastructure)
2. Machine connectors (Physical Resource)
3. Machine agent (Virtual Resource)
4. Job representatives (Job Agent)
Fig. 1. Living Lab Architecture.
The entire stack is web-based (Typescript) so end-users do
not need to install any software on their infrastructure, which is
often a challenge with an organisation’s IT policies.
The Broker (1) handles the communication between ma-
chine and job agents. The broker supports direct communica-
tion between individual agents as well as broadcasting mes-
sages to all Job and/or Machine agents. The protocol used was
socket.io, which uses the websocket protocol to establish a con-
nection between host and client. Socket.io permits multiple in-
stances of the Broker providing horizontal scaling to the ser-
vice. The Broker also features a logging service that can log all
the messages sent between the agents. This is stored as a JSON
file on the server that can be accessed via a REST API. This
is a critical feature needed to study the impact of changes to
the communication behaviour of agents and the emergent be-
haviour of the system. Authentication tokens and SSL encryp-
tion (via LetsEncrypt) are configured when the Broker service
starts providing security. The Broker also validates the mes-
sages being sent and will return an error if it does not conform
to the format specified. Agents connecting to the Broker also
need to specify the type of agent they are and the group they
belong to.
Listing 1. Message structure for communication between agents and broker
// A list of agent uuids that
// the message will go to .
to : string []
// The agent uuid the message
// originated from .
from : string
// A pre - defined subject enum .
subject : enum
// A key - value object conditional
// on the subject .
message : {[ key : string ]: any }
Listing 1 shows the message structure used to communicate
with the broker. The ‘to’ field enables an agent to supply a list
of unique agent identifiers (e.g. uuidv4 format) that the mes-
sage should be sent to. An empty list indicates a broadcast mes-
sage, i.e. a message to be sent to all agents on the network.
The ‘from’ field contains the unique agent identifier of the orig-
inating agent. The ‘subject’ field provides a meta-description
of the type of message being sent (e.g. seeking jobs, accept-
ing jobs, etc.) in line with the schema provided on instantiating
the service. The ‘message’ field then contains additional neces-
sary information, such as gcode. This approach allows for the
integration of multiple types of agents, as they simply need to
follow the message structure.
The Machine connectors (2) provide AM machine connec-
tivity enabling the web app to report the current state of a ma-
chine as well as send gcode to the machine for manufacture.
Machine connectors include:
• Manual workflows where the connector provides access
to the job gcode for download for further processing.
• Direct serial connection to a machine.
• Accessing of a machines Application Programming In-
terface (API) (e.g., Ultimaker API).
• Accessing a machine through a remote service API (e.g,
Octoprint API).
• Accessing a Fleet Manager API (e.g. Eiger.io and Ulti-
maker Digital Factory) where the connector provides ac-
cess to a set of machines.
The clients created thus far include an Ultimaker client that
talks with the Ultimaker API, an OctoPrint client that talks with
the Octoprint API, and WebUSB clients that provides a direct
serial connection to a 3D printer (Links to all the required repos-
itories may be found at: https://tinyurl.com/mhxp7dkm).
The connectors enable a range of machines to be connected to
a single network and provide the fundamental capabilities for
sending machine code to be printed, reporting printer status and
 Lorenzo Giunta et al. / Procedia CIRP 119 (2023) 656–661
cancelling prints if there is an issue, and setting a Boolean value
to indicate whether the machine is available, which in turn, per-
mits the machine agent to start looking for work.
Having connected the machines to the web app in the
browser, there needs to be a method for connecting the ma-
chine to the service and act as its representative (agent) in the
system. The Machine agent (3) class handles the connection to
the Broker, stores the metadata representation of the machine,
selects the logic used to bid for work, and passes gcode to the
Machine connector for printing. Different logics can be imple-
mented though a set of functions that listen on message events
coming from the Broker.
The Job representative (agent) (4) handles the connection to
the Broker, stores the metadata representation of the Job, and
permits a set of gcodes to support printing on multiple types of
machine. The Machine connectors, Machine agent and Job are
combined into a web application that allows an end-user, inde-
pendent of hardware and OS, to initialise and add agents to the
network. Adding multiple agents to a system can be achieved
through multiple tabs on a single computer or across multiple
computers.
4. Demonstrating the Living Lab Platform
To demonstrate the functionality of the proposed Living Lab
architecture. The Living Lab was used to create an ABMS with
four 3D printers: 2 Ultimaker 3 Extended and 2 Ultimaker S3 as
a form of ‘shakedown’ test. These were connected to the server
and assigned a coordinated manufacturing protocol. Five logics
were added to the system:
1. First Response First Serve (FRFS) – The Machine agent
accepts the first Job agent that responds to a request to be
manufactured.
2. Shortest Manufacture Time (SMT) – The Machine agent
accepts the Job agent with the shortest manufacture time.
3. Random Allocation (RA) – The Machine agent accepts a
Job at random.
4. Longest Manufacture Time (LMT) – The Machine agent
accepts the Job agent with the longest manufacture time.
5. First Come First Serve (FCFS) – The Machine agent ac-
cepts the Job agent that first entered the job pool.
Of the five considered protocols for job selection FRFS was
selected. Fig. 2 provides an example of a typical communica-
tion between the Machine and Job agents through the Broker.
While the Machine agent is in the available state, the Machine
agent will periodically send a message informing the Broker
that it is looking for jobs. The Broker will relay this message
to all Job agents connected to the network. The Machine agents
will then enter a period of ‘waiting for responses’ from the job
agents.
The Job agents will respond only if they have not been man-
ufactured. Additionally, the Job agent will check whether the
Machine agent represents an AM machine that is compatible
with the gcode held by the Job agent. If these conditions are
659
met, the Job agents respond to the Machine agent via the Bro-
ker. As a FRFS strategy was implemented, the machine will ac-
cept the first Job that messages it within the period of waiting.
The Machine agent then responds with a "machine has chosen
job" message informing the Job agent that it was selected. The
Job agent receives this message and checks whether, in the in-
tervening time, manufacturing was started by another Machine
agent. If the Job agent is still available, it will respond with a
"job has accepted offer" message that includes the gcode for the
Machine agent to begin manufacture.
Fig. 2. Example communication response between jobs and a machine in the
Living Lab. Numbering indicates the order in which the messages are sent.
Starting at (1) the Machine agent begins the interaction by seeking available
jobs.
In order to simulate a demand scenario to evaluate the effec-
tiveness of the Living Lab, a script was created to periodically
create Job agents. These would exist until a machine selected
the job for manufacture. For the purpose of this scoping study,
the item to be manufactured was a cylinder. The gcode for this
was generated in order to take approximately 10 minutes to
manufacture on both types of machines used. The service oper-
ated for a period of 3h:30m. All communications made via the
Broker were logged.
The log was post-processed to obtain the demand profile
generated by the job submission script over the 3h:30m dura-
tion of the study. This demand profile was then replicated and
inputted into an agent-based numerical model. The numerical
model was then run using the same demand profile.
The results of the model were then compared to the print
start times extracted from the logs and a comparison was made
between the two. The differences between expected print start
times, as predicted by the model, and actual start times of each
print highlights the inaccuracies and/or simplification of the
model. This allows for a better understanding of the “dead time”
that cannot be directly accounted for, such as the time required
to: clear the AM machine of the previous print, cleaning, cool-
ing/heating the bed/nozzle(s), etc.
5. Results
One observation from the setup of the Living Lab was the
ease with which the machines were connected to the network
to be able to receive jobs. The use of web technologies as the
backbone of the Living Lab setup meant that the Machine agent
could be easily and seamlessly setup on a range of hardware.
660 Lorenzo Giunta et al. / Procedia CIRP 119 (2023) 656–661
Fig. 3 shows the demand profile received by the Living Lab
during the 3h:30m study, each point on the graphic highlights a
Job agent being accepted for manufacture by a Machine agent.
A total of 43 jobs were accepted for printing. There is an incon-
sistent demand in the first hour of the study, which was caused
by technical issues preventing the Job agents from connecting
to the service. These were corrected within the first hour and a
steady state submission of jobs ensued.
A single researcher was tasked with the removal of jobs from
the machines. As part of this task, the job had to be removed
from the print bed, the machine interface cleared to mark the
print as removed, and the web interface accessed to inform the
Machine agent that all this had occurred so that it could accept
new jobs. No filament changes were required during the ses-
sion.
0:00 0:30 1:00 1:30 2:00 2:30 3:00 3:30
Submission Time [HH:MM]
Fig. 3. Submission of jobs to the LL over a 3.5-hour period.
Fig. 4 shows a histogram highlighting the difference in the
real start times of the jobs and the start times as predicted by
the model against the frequency (Count #) with which this dis-
crepancy occurs. The result is a normal distribution indicating
a consistent error around the -2 minute mark. The negative sign
indicates the real values are lagging behind those calculated by
the numerical model.
10
Count [#]
5
0 the system operated as expected and did not experience capac-
-7 -6 -5 -4 -3 -2 -1 0 1 2 3 4 5
Δ Start Time [min]
Fig. 4. Delta histogram in the LL and numerical model job start times (real -
computed).
6. Discussion
The study detailed in this paper has highlighted a number
of findings. Firstly, assuming that the “dead time” required for
each print was zero, within the 3.5 hour timeframe for the study
84 jobs should have been processed (10 minutes required per
job, over 4 machines). This implies only half of the absolute
maximum number of jobs was processed.
However, as previously mentioned, and highlighted in Fig. 3,
the first hour of the study resulted in few prints being accepted
due to technical issues. If the expected number of prints is cal-
culated based only on a 2.5 hour timeframe, the maximum num-
ber of prints expected becomes 60.
It is possible then to further refine this prediction using the
findings highlighted in Fig. 4. If the number of prints is cal-
culated on the basis of a 12-minute timeframe, rather than the
predicted 10, 50 prints are then expected over the 2.5 hours of
the study. This is more consistent with the actual number of
prints generated by the ABMS deployed in the Living Lab and
demonstrates the utility of using empirical studies to tune our
agent-based numerical models.
This 2 minute discrepancy represents a 20% deviation when
based on the expected print time of 10 minutes for each part.
While this may seem particularly noteworthy, it is necessary to
understand whether the 2 minute deviation is a static constant
or scales with the print time required. Additional exploration
would be required, in particular to understand how this time is
impacted by other variables, such as material changes. Either
outcome would have significant impact for the computational
model’s design.
The study reinforces both the value of ABMS as a tool to
manage manufacturing and the value of a Living Lab to re-
search. A single operator was able to effectively monitor and
maintain the output of 4 AM machines as well as adjust the en-
tire Living Lab setup when a fault was detected. This finding is
encouraging for the future potential of the Living Lab as a tool
for research and data collection. It also strengthens the claim
that the use of ABMS can aid in improving the responsiveness
of manufacturing by highlighting how the need for operator in-
put is reduced when the Job and Machine agents can indepen-
dently handle the job acceptance process.
Additional improvements will be necessary for wider adop-
tion of the ABMS developed for this study, such as added track-
ing for the individual machines joining the network rather than
the jobs and agents themselves. This will improve error de-
tection and aid operators in responding to issues more rapidly.
However, the results obtained are already encouraging as, bar-
ring the single error with job agents not correctly connecting,
6 7 ity issues, allowing for expansion if needed.
The platform is now in use at the University of Bristol with
students submitting their work for printing. This will provide
the foundation for a longitudinal study into the usage of an
ABMS that may then be correlated to numerical models and
used to categorize the types of errors, and other forms of “dead
time”, that occur when running a real-world ABMS system.
7. Conclusion
The paper has provided an overview of an ABMS deployed
at the University of Bristol. The paper discussed the ABMS de-
ployment and how the system was structured. The paper then
presented a scoping study performed to better understand the
value of ABMS as a tool to manage manufacturing. Further-
 Lorenzo Giunta et al. / Procedia CIRP 119 (2023) 656–661
more, the paper attempts to understand the potential shortcom-
ings in the modelling techniques used to model the behaviour
of ABMS.
The findings highlighted by the work performed have evi-
denced the value of ABMS, allowing a single user to monitor
multiple AM machines. Furthermore, the ABMS did not require
major intervention once in place and functioning, all the deci-
sions for the allocation of jobs were taken care of by the agents
themselves.
The software stack presented in this paper to setup the Living
Lab used to run the experiments, made available via an open-
source licence, has proven itself as a successful springboard for
future exploration of ABMS. It’s flexibility and ease of deploy-
ment allow for it to be adopted and adapted for future studies.
The findings from the empirical scoping study provide valu-
able insights into the limitations of current modelling ap-
proaches for ABMS. Specifically, the study highlighted the po-
tential issue caused by “dead time”, which occurs when ma-
chines are idle due to operator input. These insights can in-
form the numerical work previously undertaken by improving
predictions for manufacturing output, leading to more accurate
production goals and quotas. Additionally, understanding the
causes of “dead time” can inform optimization efforts in the job
allocation process and machine agent interactions, ultimately
increasing process efficiency. “Dead time” notwithstanding, the
findings of this empirical study are broadly aligned with those
predicted by the numerical model. This reaffirms the value of
numerical models for prediction, barring some minor improve-
ments, as a tool to inform and improve ABMS.
Moving forward, the usability of the ABMS should be fur-
ther explored to evaluate the impact of new functionalities. Ma-
terial changes, for example, have not been sufficiently explored.
The optimisation of models and the calculation of “dead time”
when operators have to manually change the material fed into
the AM machine could be of great interest for further optimis-
ing the job selection logic used by the Machine agents.
References
[1] Catapult, T.D., 2018. The rise of distributed autonomous manu-
facturing. URL: https://www.digicatapult.org.uk/wp-
content/uploads/2021/11/The_rise_of_distributed_
autonomous_manufacturing.pdf.
[2] Duffie, N.A., 1996. Heterarchical control of highly distributed manufactur-
ing systems. International Journal of Computer Integrated Manufacturing
9, 270–281. doi:10.1080/095119296131562.
[3] Forum, W.E., 2021. Net-zero challenge: The supply chain opportu-
nity. URL: https://www3.weforum.org/docs/WEF_Net_Zero_
Challenge_The_Supply_Chain_Opportunity_2021.pdf. [Ac-
cessed: 07.03.2023].
[4] Giret, A., Botti, V., 2004. Holons and agents. Journal of intelligent manu-
facturing 15, 645–659. doi:10.1023/B:JIMS.0000037714.56201.a3.
[5] Gopsill, J., Obi, M., Giunta, L., Goudswaard, M., 2022. Queueless: Agent-
based manufacturing for workshop production, in: Jezic, G., Chen-Burger,
Y.H.J., Kusek, M., Šperka, R., Howlett, R.J., Jain, L.C. (Eds.), Agents and
Multi-Agent Systems: Technologies and Applications 2022, Springer Na-
ture Singapore, Singapore. pp. 27–37.
[6] Huang, S.H., Liu, P., Mokasdar, A., Hou, L., 2013. Additive manufacturing
and its societal impact: a literature review. The International journal of ad-
661
vanced manufacturing technology 67, 1191–1203. doi:10.1007/s00170-
012-4558-5.
[7] Kuuse, M., 2022. What is distributed manufacturing? URL: https:
//manufacturing-software-blog.mrpeasy.com/distributed-
manufacturing/.
[8] Leitão, P., Restivo, F., 2006. Adacor: A holonic architecture for agile
and adaptive manufacturing control. Computers in Industry 57, 121–130.
doi:10.1016/j.compind.2005.05.005.
[9] Lim, M., Zhang, D., 2004. An integrated agent-based approach for respon-
sive control of manufacturing resources. Computers & Industrial Engi-
neering 46, 221–232. doi:10.1016/j.cie.2003.12.006. special Issue
on Selected Papers from the 27th. International Conference on Computers
and Industrial Engineering, Part 1.
[10] Luman, R., Fechner, I., 2022. Trade outlook 2023: slow steaming in rough
water. URL: https://think.ing.com/downloads/pdf/article/
trade-outlook-slow-steaming-in-rough-waters-what-to-
expect-in-2023. [Accessed: 07.03.2023].
[11] Ma, A., Frantzén, M., Snider, C., Nassehi, A., 2020. Anarchic manufactur-
ing: Distributed control for product transition. Journal of Manufacturing
Systems 56, 1–10. doi:10.1016/j.jmsy.2020.05.003.
[12] Ma, A., Nassehi, A., Snider, C., 2019. Anarchic manufacturing. Inter-
national Journal of Production Research 57, 2514–2530. doi:10.1080/
00207543.2018.1521534.
[13] Ma, A., Nassehi, A., Snider, C., 2021. Anarchic manufacturing: imple-
menting fully distributed control and planning in assembly. Production
& Manufacturing Research 9, 56–80. doi:10.1080/21693277.2021.
1963346.
[14] Mönch, L., Stehli, M., Zimmermann, J., 2003. Fabmas: An agent-based
system for production control of semiconductor manufacturing processes,
in: Holonic and Multi-Agent Systems for Manufacturing: First Interna-
tional Conference on Industrial Applications of Holonic and Multi-Agent
Systems, HoloMAS 2003, Prague, Czech Republic, September 1-3, 2003.
Proceedings 1, Springer. pp. 258–267.
[15] Obi, M., Snider, C., Giunta, L., Goudswaard, M., Gopsill, J., 2022. Coping
with diverse product demand through agent-led type transitions, in: Jezic,
G., Chen-Burger, Y.H.J., Kusek, M., Šperka, R., Howlett, R.J., Jain, L.C.
(Eds.), Agents and Multi-Agent Systems: Technologies and Applications
2022, Springer Nature Singapore, Singapore. pp. 277–286.
[16] Radius, F., 2021. Why distributed manufacturing is the future
of production. URL: https://www.fastradius.com/resources/
distributed-manufacturing-benefits.
[17] Real, R., 2022. Injection moulding plastic lfd cases with re-
cycled facemasks. URL: https://dmf-lab.co.uk/blog/
recycling-facemasks-into-covid-test-cases-with-rapid-
prototyping/. [Accessed: 2023.03.08].
[18] v.H. Remko, . Research opportunities for a more resilient post-covid-19
supply chain – closing the gap between research findings and industry prac-
tice. International Journal of Operations & Production Management 40,
341–355. doi:10.1108/IJOPM-03-2020-0165.
[19] Toor, R., 2021. The uk 3d printing filament market in 2021.
URL: https://www.filamentive.com/the-uk-3d-printing-
filament-market/.
[20] Ultimaker, 2021. The uk 3d printing filament market in 2021.
URL: https://ultimaker.com/3d-printing-sentiment-index/
overview/uk. [Accessed: 2023.03.08].
[21] Valckenaers, P., Van Brussel, H., Bongaerts, L., Wyns, J., 1997. Holonic
manufacturing systems. Integrated Computer-Aided Engineering 4, 191–
201. doi:10.3233/ICA-1997-4304.
[22] Van Brussel, H., Wyns, J., Valckenaers, P., Bongaerts, L., Peeters, P., 1998.
Reference architecture for holonic manufacturing systems: Prosa. Comput-
ers in Industry 37, 255–274. doi:10.1016/S0166-3615(98)00102-X.