Smart Factory Web—A Blueprint Architecture for Open Marketplaces for Industrial Production

Featured Application

The result of this work may be applied in the architectural design and development of electronic marketplaces if they claim to be usable in open ecosystems following the paradigms of the platform economy. Although the work is primarily dedicated to industrial production, its principles may also be applied to other markets and domains of the Industrial Internet of Things such as health, logistics or mobility.

Abstract

The paper describes a reference architecture for open marketplaces to be used for networked stakeholders in industrial production ecosystems. The motivation for such an endeavor comes from the idea to apply the basic principle of the platform economy to offer functions of an asset “as a service” to industrial production, including the associated supply chain networks. Currently, commercial offers of “production as a service” usually lead to proprietary systems with the risk of platform vendor lock-ins. Hence, there is a need for an open approach that relies upon international (emerging) standards, especially those from IETF, IEC, the Plattform Industrie 4.0 and the International Data Spaces Association (IDSA). The presented approach enables federation of marketplaces according to well-defined interfaces. This article proposes a technology-independent open architecture derived from functional and non-functional system requirements and driven by the idea of the Smart Factory Web, a testbed of the Industrial Internet Consortium (IIC). Furthermore, the architecture of the Smart Factory Web (SFW) platform is presented and assessed against the current and future demands of open federated marketplaces for industrial production ecosystems.

1. Motivation

1.1. Platform Economy

“Tomorrow’s supply chains will be connected and self-orchestrated ecosystems.” This is the introductory statement of a PwC study on “Connected and autonomous supply chain ecosystems 2025” (https://www.pwc.de/en/digitale-transformation/connected-and-autonomous-supply-chain-ecosystems-2025.html, accessed on 15 July 2021). Driven by the need to increase the robustness and sustainability of their supply chains, also in light of delivery and ecological risks, original equipment manufacturers (OEM) aim at obtaining more insight into the ability of their suppliers to deliver the goods and materials as promised or contractually assured. However, the suppliers have an interest in having more dependable information about the long-term orders of the OEMs in order to schedule their production capacities in advance.

Furthermore, with the current, politically influenced tendencies towards regional supply chain approaches and the noticeable effects of the COVID-19 pandemic on supply, globalization is at a turning point. Due to the successive increase in the dependency of industry and trade on multinational supply networks or supply chains, the decade that has just begun tends to bring about a change in thinking. As a result, the supply networks, whose unbundling will take years, are subject to greater dynamics than before in terms of market participants, interactions and service provision.

When supply chains are transforming into self-orchestrating, autonomous ecosystems, high volatility and vulnerability due to multiple risks force short-term, situation-dependent adaptation measures.

One of the adaptation measures refers to the possibility to bring more flexibility into the supply chains by applying the principles of the platform economy to industrial production systems. According to [1], the term platform economy simply “encompasses a growing number of digitally enabled activities in business, politics, and social interaction.” More concretely, ref. [2] states that “platform economy (also known as collaborative platform economy or sharing economy) is used as a floating signifier for interactions among distributed groups of people supported by digital platforms that enable them to exchange (matching supply and demand), share, and collaborate in the consumption and production of activities leveraging capital and goods.” For the application domain of industrial production, this includes marketplaces that offer “production as a service”, i.e., they allow the mediation of a customer request for delivery of a product with given criteria and characteristics with a supplier’s capability to produce such a product according to these criteria and characteristics.

The challenges for the development of such marketplaces are multi-fold as they require an alignment between the business and information technology (IT) strategy [3]:

• Business managers ask:
  • What are the associated business models, for each of the stakeholders involved?
  • How shall they be designed such that, for all stakeholders involved, there are fair conditions as well as sufficient incentives to participate?
• System architects resp. IT experts ask:
  • What is the best IT strategy and technical architecture to support these business models?
  • What are the resulting system requirements that serve as design parameters for the architecture?

In the following sub-section, this paper gives a broad overview of the motivational business models, but focuses subsequently on the questions of the system architects and describes how an open architectural approach should look in order to avoid platform vendor lock-in situations. The Smart Factory Web is described on two levels: firstly, as a blueprint architecture for a Web of Smart Factories forming an industrial marketplace in a federated ecosystem, and secondly, as a software system that realizes this idea based upon international standards.

1.2. Business Models

In [4], 55 innovative business models that are in widespread use in today’s economy are presented. Of these, we briefly explain five with a high degree of relevance for industrial production marketplaces. The following list refers to the business model number in [4], whereby we have grouped similar business models:

• BM2 Affiliation, BM37 Peer to Peer, BM52 Two-sided Market: support others to market products; brokering of peer to peer relationships; lending/sharing resources with trustworthy and efficient transactions; facilitate interactions between independent groups of customers, e.g., between providers and users of a technology or machine; broker deals between buyers and sellers
• BM30 Mass Customization: efficient product customization to meet customer needs; using standardized modular product architectures with standardized product description formats.
• BM32 Open Business: open, collaborative value creation chains; collaborative product design and production engineering. The aim is to establish an ecosystem of synergetic companies to create greater customer value.
• BM34 Orchestrator: coordination and matching of individual value creation activities in a value chain. The orchestrating company manages and directs the entire value chain, focusing on its key strengths and outsourcing other activities.
• BM54 User Design: platform supports customers to design and market their products. There is a strong focus on co-design in a network of partners. The main process steps are idea initiation, product co-design, production and sales.

Further background information on business models in the platform economy can be found in [5,6]. A business model in industrial production typically focuses on a given production domain, i.e., a category of products (e.g., metal parts) or processes (e.g., CNC machining). A domain may be divided into sub-domains with more specific constraints. The platform earns income through service commissions and ads. The value chain participants (e.g., factories, designers etc.) benefit from higher visibility and efficient transactions at lower cost. These benefits vary in detail amongst the BMs in the list above.

1.3. Structure of the Paper

The remainder of the paper is structured as follows. Derived from a role model of marketplace stakeholders, Section 2 provides a list of technology-independent system requirements for open industrial production marketplaces. The state of the art, especially an assessment of the existing approaches w.r.t. the system requirements, is given in Section 3. Section 4 presents the Smart Factory Web as it was proposed and realized as a testbed of the Industrial Internet Consortium (IIC). The architectural approach of the Smart Factory Web and some core processes including the supply chain integration are presented in Section 5. Section 6 describes the validation of this approach in international smart factory markets, especially in South Korea and Japan, before Section 7 concludes with an outlook to future developments and initiatives.

2. System Requirements

The business models in Section 1.2 assume a common set of stakeholders as well as the fulfillment of the functional and non-functional requirements of industrial production marketplaces. These are described in this section in a conceptual, technology-independent way. Note that in the following, we use the following terms:

• The term “service” always refers to a production service.
• The term “industrial marketplace” denotes a marketplace for industrial production. The applicability to other application domains beyond “production” is possible, of course, but not considered in this paper.
• The term “asset” refers to an “entity which is owned by or under the custodial duties of an organization, having either a perceived or actual value to the organization” [2].

2.1. Stakeholders

Figure 1 shows possible stakeholders of industrial marketplaces and their basic interactions. Industrial marketplaces typically act as service brokers that mediate a (production) service between service requesters and service providers. Service requesters use industrial marketplaces to request services from service providers via the marketplace. Service brokers can be in a federation of industrial marketplaces to extend functionalities.

Table 1. Stakeholder roles of industrial marketplaces (note: the prefix [Service] is optional).

Role Name	Description
[Service] Provider	Provider of production capabilities by means of production assets (e.g., factory or machine within a production plant)
[Service] Requester	Requester of services to be provided by manufacturers, suppliers, systems, etc.
[Service] Broker	Mediates the (production) service between the service requestor and service provider according to the constraints given by the legislator and compliant to defined rules Note: A service broker may act as both service requestor and service provider in order to generate federations of marketplaces
Legislator	Defines and provides the legal, ethical and trade constraints for the production ecosystem
Compliance Checker	Checks if the constraints given by the legislator are fulfilled
App Store	Provides software applications that may be loaded into the service broker in order to support and enable its functionalities

lists and defines possible stakeholders of industrial marketplaces. Note that service brokers may also be service requestors and providers. By this means, a federation of industrial marketplaces may be built.

2.2. Functional and Non-Functional Requirements

User and system requirements are often classified as functional requirements, that define what the system should do, and non-functional requirements that define constraints on the system or on the process to design the system [7]. A system, of course, has to fulfill the functional requirements; however, the non-functional requirements determine the architectural patterns used and serve as design parameters. This is also the case for industrial production marketplaces. The stakeholders listed above have functional and non-functional requirements, which are described below in

Table 2. Functional requirements (M = mandatory, O = optional).

No	Requirement	Stakeholder Roles	Business Models	Priority
FR01	Provision of a flexible, domain-independent data model to describe production assets, capabilities and properties, including supply chain characteristics	Broker	all	M
FR02	Registration of factories based on the capability model and open standards (e.g., of the Platform Industrie 4.0) to describe the production capabilities and capacities of the factories	Provider	BM {2,37,52}, BM30, BM34	M
FR03	Search for factories, factory assets and supply chains for a required production process	Requester, Broker	BM {2,37,52}, BM30, BM34	M
FR04	Matchmaking between production process description of a production request and the capabilities and capacities of registered factories, including their supply chains	Broker	BM {2,37,52}, BM30, BM34	M
FR05	Ranking of search results according to user preferences	Requester, Broker	all	O
FR06	Query the availabilities of factories and factory asset in (near) real time, i.e., respecting the time constraints of the use case	Requester, Provider	BM {2,37,52}, BM30, BM34	O
FR07	Generate, manage, query and analyze supply chains.	Broker	BM {2,37,52}, BM {30,32,34}	O
FR08	Visualization of shop floor data (machines, etc.)	Provider	BM30, BM34	M
FR09	Visualization of supply chains/supply networks	Provider	BM30, BM34	M
FR10	Detection and visualization of supply chain interruptions	Provider	BM30, BM34	O
FR11	Defining redundant supplier structures	Provider	all	O
FR12	Validation of quality/sustainability criteria along the supply chain (e.g., carbon footprint)	Compliance Checker	BM {2,37,52}, BM {30,32,34}	O
FR13	Provision of additional functionalities for the use of the marketplace via an app store	Requester	all	O
FR14	Provision of an open, standardized interface for connecting external platforms/marketplaces (federations)	Broker	all	O
FR15	Provision of a means to download software applications from an app store to enhance or tailor the functionality	Broker	all	O
FR16	Provision of means to adapt the information model and functionality of the service broker to new contexts and situations	Broker	all	M

and

Table 3. Non-functional requirements of the marketplace architecture (M = mandatory, O = optional).

Number	Requirement	Priority
NFR01	Interoperability with other industrial marketplaces and software systems (support for federations)	M
NFR02	Applicability to new industrial domains and sub-domains	O
NFR03	Openness in the sense of supporting international and national standards to avoid vendor lock-in and follow future technological trends	M
NFR04	Adaptability to new business models	M
NFR05	Scalability of user, data and app management	M
NFR06	Security to protect company data from unauthorized access and assure its integrity	M
NFR07	Data Sovereignty to maintain control over the complete processing chain of data and also the independent decision on who is permitted to have access to it	M
NFR08	Extensibility to support new types of production assets (e.g., virtual assets such as production-related services)	O

, respectively.

Not illustrated in Figure 1, but highly relevant for the service providers in marketplaces for industrial production, is the supply chain management. According to [8], supply chain management “encompasses the planning and management of all activities involved in sourcing and procurement, conversion, and all logistics management activities.” Driven by demands to ensure sustainability and to enable risk management of product delivery, producers have to look behind their one-tier suppliers to obtain information about the supply chains. The term supply chain is defined in [8] as “the material and informational interchanges in the logistical process stretching from acquisition of raw materials to delivery of finished products to the end user.” When applied to the role model in Figure 1, a supply chain is represented by a sequence of provider/requestor relationships between service providers, especially in the form of factories.

The business models raised in Section 1.2 may only be realized if the stakeholders may place an adequate level of trust in the industrial marketplace, as their business success relies upon it and data need to be shared with the service broker. Hence, the trustworthiness of the industrial marketplace and the overall architectural approach need to be assured. In [9], trustworthiness is defined as “The degree of confidence one has that the system performs as expected with characteristics including safety, security, privacy, reliability and resilience in the face of environmental disturbances, human errors, system faults and attacks.” The degree of fulfillment of these characteristics is dependent on the use case and the business model behind them.

3. State of the Art

This section provides an overview of existing approaches and systems that are classified as approaches to realize Manufacturing as a Service (MaaS) or fall into the product category of an industrial marketplace.

3.1. Manufacturing as a Service (MaaS)

MaaS platforms take a detailed product description as an input (often including CAD files to describe the product geometry) and determine how and by whom the product can be manufactured as a customized production service. Typical production processes are:

• CNC machining;
• Three-dimensional printing;
• Urethane casting;
• Sheet metal fabrication;
• Injection molding.

The other main aspect of the MaaS is the material type, which may also be hierarchically structured. Materials at the top level are metal, rigid plastics and elastomers. An essential part of the platform service is to check the manufacturability of the product with the proposed process and materials (e.g., are connecting elements too weak, or are holes in 3D objects too difficult to produce?). Platforms may offer to modify the design (Design for Manufacturing) and optimize the production process with regard to cost and quality.

The platform service may also include the desired product finishing. Metal finishing in particular has many different options, e.g., relating to anodizing, plating, media blasting, powder coating and tumbling. The MaaS platform provides a quotation (‘instant pricing’) for the requested manufacturing capability. Examples of process-dependent properties of the factory capabilities are:

• Min and max of the product sizes;
• Minimum hole size;
• Tolerances;
• Production time;
• Field of application (e.g., exclusion of fields where products must be certified).

Several examples of MaaS platforms and their offered processes are given in

Table 4. MaaS platform examples and references (accessed on 16 July 2021).

MaaS Platform	URL	Range of Manufacturing	Main Market
fictiv	www.fictiv.com	3D printing, CNC machining, injection molding and urethane casting	USA, China
Fractory	fractory.com	Sheet metal fabrication	UK
Haizol	www.haizol.com/en	Machining, molding, fabrication, casting, stamping	Asia
Hubs	www.hubs.com	CNC machining, 3D printing, sheet metal fabrication, injection molding	Worldwide
Istawerk	www.instawerk.de	CNC turning and milling	Germany
laserhub	laserhub.com	Laser cutting, metal forming, CNC milling	Germany, Austria, France
macrofab	macrofab.com	Printed circuit board assembly	North America
mipart (of BAM GmbH)	mipart.com	CNC turning and milling, rapid prototyping, small series	Focus Germany
Plethora	www.plethora.com	CNC machining (mainly for military and defence)	USA
spanflug	spanflug.de	CNC turning and milling	Focus Germany
up2parts	www.up2parts.com	Wide range of processes	Germany
Weerg	www.weerg.it	3D printing, CNC machining, finishing	Italy
Xometry	www.xometry.com	Wide range of processes	Worldwide, focus USA

(in alphabetic order) with no claim to completeness, and just based upon publicly available information.

A detailed comparison would require a survey, which is beyond the scope of this article. However, as a common denominator, all of these platforms address a limited range of manufacturing processes (mostly CNC machining) or focus on dedicated market segments or regions. None of these platforms, as of today, aim at leveraging a network of marketplaces or a production ecosystem and therefore do not support the non-functional requirements of interoperability, openness and data sovereignty as required in Table 3.

3.2. Industrial APP Marketplace

In smart production systems, components negotiate with each other to fulfill tasks with predefined characteristics in a defined period of time, with a defined quality of service and a defined cost range. In order to enable production system components to cooperate in such a way, they must be able “to speak a common language” within a shared communication and exchange infrastructure. The Industrial APP Marketplace [10] proposes an open architecture for vendor-neutral marketplaces for production assets to buy and sell industrial hardware, software and services. Unlike conventional virtual marketplaces, the Industrial APP Marketplace is an autonomous and decentralized platform for offering and searching for hardware, software and services, free of charge or paid (as a service) and open to everyone. The concept of the Industrial APP Marketplace may be used to realize the stakeholder “App Store” of the SFW as illustrated in Figure 1.

A participant in an Industrial APP Marketplace can take up to four roles: the role of an app user, hardware developer, app developer or integrator. Basically, the term “app” refers to modern software applications which are modular and provide a user-friendly interface in a Web Browser, but in the context of an Industrial APP marketplace, also services and solutions. The APP User searches for some services or solutions, e.g., data logging, process visualization, predictive maintenance, etc., offered by the Industrial APP marketplace. The APP Developer, Hardware Developer and the Integrator issue a call for a proposal in which they specify their requested service. The Industrial APP Marketplace can then generate proposals in response to the APP User. Both the call for proposal and the proposal itself contain a technical and commercial description of the service. This can include, for example, the price, time, quality and place for the provision of a service. The demand of the industry for such marketplaces is formulated in [11,12].

4. IIC Testbed Smart Factory Web

The idea of the Smart Factory Web (SFW) originated in a testbed of the Industrial Internet Consortium (IIC) (https://www.iiconsortium.org/test-beds.htm, accessed on 15 July 2021) initiated by Fraunhofer IOSB and the Korean research partner Korea Electronics Technology Institute (KETI) in 2016. The primary goals of the Smart Factory Web testbed have always been:

• Achieve a flexible adaptation of production capabilities and sharing of resources and assets in a web of Smart Factories to improve order fulfillment.
• Provide the technical basis for new business models with flexible assignment and sharing of production resources.

Since its approval as an IIC Testbed in 2016, the Smart Factory Web Testbed has attracted participation by global IT players such as Microsoft and SAP to jointly leverage commercial business cases. There is also a link to the IIC testbed Negotiation Automation Platform led by NEC which applies the SFW for the registration and search for suitable manufacturing resources. Details of the SFW Testbed may be found in [13,14].

Figure 2 shows the overall workflow of the SFW. In the first step, “Asset Registration and Search”, assets (manufacturing resources such as factories or machines) are registered on SFW with a description of their capabilities. Capabilities can be expressed in terms of what the asset produces (e.g., a computer mouse as a product) or in terms of how the asset produces, processes or transforms a product (e.g., 3D printing, or metal cutting and bending). Registered assets can be searched for on SFW on the basis of their capabilities as well as other metadata such as location. A client of the SFW may search for a set of candidate assets able to perform an overall manufacturing task, e.g., as represented by a supply chain or production diagram. The next step is to negotiate with the candidate assets on delivery terms and conditions such as price, time, quantity and quality. The negotiation procedure may be manual or supported by platforms such as the Negotiation Automation Platform (https://hub.iiconsortium.org/negotiation-automation-platform, accessed on 15 July 2021) of NEC (see Section 7.1) that uses AI techniques to facilitate the solution of the complex multi-constraint, multi-objective optimization problem. The result of this second step is the selection of assets to accomplish the overall manufacturing task. The third step in the workflow comprises the ordering, operation and monitoring of the manufacturing steps in the selected assets. Assets can provide operational reports to the SFW. These can be at machine level (e.g., for quality control or machine maintenance purposes), or simply give the status of the order processing. All three steps may require confidential, commercially sensitive information to be exchanged. The usage control for such information can be specified and implemented with the technologies of the International Data Spaces (IDS) Association [15], such as the IDS Connector [16].

5. Smart Factory Web Approach

5.1. Motivation

There are significant technical challenges to realizing the SFW vision as sketched above. The Smart Factory Web provides an open software architecture that enables the design and set-up of sustainable and resilient industrial ecosystems [14]. As such, it claims to define a blueprint architecture to be instantiated depending on the intended purpose. For instance, the SFW may be instantiated as an open marketplace for industrial production, including their supply chains, but also as a research platform for AI-based negotiation protocols in marketplaces, or as a testbed technology to validate the interoperability of IIoT technologies according to the specifications of the Platform Industrie 4.0, the Industrial Internet Consortium (IIC) and the IDS [15].

In its form as an enabler for marketplaces it appears as the Smart Factory Web portal, i.e., as a service platform with a human, Web-based interface where factories can offer production capabilities and share resources. This enables them to improve order fulfillment with greater flexibility than is currently possible with available technology. The SFW seeks to provide the technical basis for new business models, especially for small lot sizes, by flexibly assigning production resources across factory locations.

This testbed is chiefly designed as a step towards establishing a manufacturing marketplace where one can look for factories with specific capabilities and assets to meet production requirements. Factories with those capabilities can then register to join the marketplace. This requires up-to-date information about the capabilities and status of assets in the factory. The specifications of the products—availability, quality and price as well as information about the supply chain—may be provided at the discretion of the factories in order to be able to participate fully in the negotiation process in case of competing offers. Another reason to provide such information is to fulfil compliance requirements on production and supply chains. The usage of this information may be subject to restrictions and in general needs data sovereignty concepts.

5.2. Architecture Overview

Figure 3 shows the Smart Factory Web architecture as a UML diagram. The core element is the SFW platform that consists of a SFW service framework that provides the services via well-defined interfaces to SFW users. The underlying WebGenesis^® service framework is a development platform for knowledge-based systems (https://www.iosb.fraunhofer.de/en/projects-and-products/webgenesis.html, accessed on 15 July 2021). The SFW users may act in the roles of requestors, brokers or providers (see Section 2.1). Hence, service providers can register their factories and machines via the SFW Service interface. In case the SFW user is a human, the SFW services are accessible via a (preferably Web-based) user interface, and then act as an SFW portal. The SFW service framework can reach external services by dedicated external service interfaces, preferably based upon standards such as IEC 62541 OPC UA (https://opcfoundation.org/developer-tools/specifications-unified-architecture, accessed on 15 July 2021) (e.g., to retrieve production asset data) or the OGC SensorThings API (https://www.ogc.org/standards/sensorthings, accessed on 15 July 2021) (e.g., to retrieve sensor data related to the production in a plant). The SFW Service framework can be extended via “apps” downloaded from an SFW App Store and deployed as further SFW services.

Figure 4 shows some details of the SFW architecture with the technologies and open standards used on the part of the SFW platform, the service providers and requesters. Service requesters can access the SFW search service via the IETF Hypertext Transfer Protocol Secure (https) and via the Industrie 4.0 Asset Administration Shell (AAS) interfaces. Service providers can be connected to the SFW platform using the following technologies:

• AAS or AutomationML for factory registration.
• Open Geospatial Consortium (OGC) SensorThings API and IEC 62541 OPC UA for connecting machines and sensors.
• IDS for secure and trusted data exchange in business ecosystems [15].

The SFW platform provides service requesters platform-specific services such as registration and matchmaking. In addition, external services can be connected via the platform API to extend the range of functions. The SFW platform is therefore modular and flexibly extensible.

5.3. Factory Registration and Interoperability

One of the main tasks of a marketplace is to provide registration and search services. However, usually, the barriers to information acquisition are high, mainly due to syntactical and semantic interoperability problems in both the provision of information and the use of the information provided. Regarding registration, providers typically have their own model of services and products, which usually does not match the internal model of the marketplace. As manual registration is a time-consuming and error-prone activity, there is a need for methods and tools to facilitate automated registration.

SFW solves syntactic interoperability by using standard communication protocols (e.g., https://datatracker.ietf.org/doc/html/rfc2818, accessed on 15 July 2021), common data formats (e.g., IEC 62471 AutomationML (https://www.automationml.org/o.red.c/publications.html, accessed on 15 July 2021) and IETF JavaScript Object Notation (JSON (https://datatracker.ietf.org/doc/html/rfc7159, accessed on 15 July 2021))), common architectural styles (e.g., REpresentational State Transfer (REST) (https://tools.ietf.org/id/draft-keranen-t2trg-rest-iot-05.html, accessed on 15 July 2021)) and standard communication frameworks (e.g., IEC 62541 OPC UA (https://opcfoundation.org/developer-tools/specifications-unified-architecture, accessed on 15 July 2021)). On the other hand, semantic interoperability requires a precise interpretation of the information provided by the marketplace players in order to understand it. Smart Factory Web describes factories as a hierarchy of assets, including their capabilities and properties. This data model is represented in the SFW ontology in Figure 5.

The individual ontology concepts are defined in more detail in

Table 5. Description of the ontology concepts.

Ontology Concept	Definition
Asset	Asset is a factory or part of the factory equipment hierarchy as defined in [17]. In the context of SFW, an asset can be a supplier for another factory. Examples of an asset in SFW: factory, supplier, manufacturer, distributor, retailer, production line, production machine, manufacturing resource, sensor, etc.
Capability	Capability (of an asset) is described in terms of its input and output products and their respective properties, and/or in terms of how the product can be produced. The capability concept enables the modeling of process steps (BOP Bill of Process, e.g., manufacturing processes for the production of a product).
Product	Input (materials, part products) or output (result) of a production process. The product structure (BOM Bill of Material—structured arrangement of objects, e.g., components) in the SFW platform can be described using the concept product and the corresponding inverse relation.
Property	The property concept is used to describe capabilities and products in more detail. There are no particular restrictions on properties. These may cover a broad spectrum such as production rates, physical dimensions, materials, carbon footprint, fair trade compliance, etc.
Unit of Measure	The Unit of Measure concept specifies units of measurement for properties (e.g., kilogram, liter, piece, etc.).

. Table 5 describes the required ontology concepts for modeling production, process steps and supply chains. The relations between the concepts are defined in

Table 6. Description of the ontology relations.

Ontology Relation	Definition
isSubAssetOf (isSuperAssetOf)	An asset, e.g., a production line, consists of several robots that work together. These can be related to the production line via the relation isSubAssetOf.
hasSupplier (isSupplierTo)	Enables the linking of assets, i.e., the description of supplier relationships between two factories.
offersProduct (offeredBy)	Allows an asset (e.g., manufacturer, supplier) to be associated with a product that is being manufactured or supplied.
isSubProductOf (hasSubProduct)	The subproducts of a product can be described with the relation isSubProductOf. The relation hasSubProduct allows conclusions to be drawn about the respective subproducts of a product. The subproducts in turn allow conclusions to be drawn about the producing companies that manufacture these subproducts (relation offeredBy).
hasInputProduct (isProcessedBy)	In a production process, input products (materials, subproducts, components, etc.) are further processed into output products. The relation hasInputProduct enables the link to the input products.
hasOutputProduct (isCreatedBy)	The relation hasOutputProduct enables the link to the created output products.
hasProductProperty (specifiesProduct)	Relation between a product and a property to describe the characteristics of a product in more detail.
hasCapability	Relation between an asset and an ability to specify the capabilities of an asset.
hasProperty	Relating a capability to a property to describe the characteristics of a capability in more detail.
hasUnitOfMeasure	Relation between a property and a unit of measurement to specify the properties definitively with the associated unit of measurement.

. The respective inverse relation is shown in italics.

The SFW capability ontology is the right way to achieve semantic interoperability. However, it is expected that either:

• Providers are aware of the SFW capability ontology and have prepared their registration information as instances of this ontology, or;
• Developers should be involved to ensure that provider information is accurately mapped to the SFW capability ontology. This requires negotiation with each provider individually to agree the mappings.

To speed up registration and facilitate maintenance of registered information, interoperability could be further improved by using the Industrie 4.0 Asset Administration Shell (AAS) for registration. The AAS concept and meta-model is about to be standardized on the IEC level. Furthermore, there are multiple activities to agree upon AAS sub-models in industrial communities (dedicated to certain asset types and processes) with semantic definitions defined by ECLASS and other international vocabularies such as IEC Common Data Dictionary. Hence, it is expected that by means of the AAS approach it may be possible to increase the degree of automation in the registration process while ensuring that the registered information is properly understood.

In addition, there is the lack of interoperability between the marketplaces. In order to enable the SFW to interact with similar platforms, the SFW itself should be made available via AAS interfaces. This will ensure that the other actors (marketplaces or software systems) not only understand the SFW data but can also use its services (e.g., search) in an Industrie 4.0-compliant way.

5.4. Search for Production Capabilities

This section describes an exemplary approach for the unified description of production processes and the search for production capabilities of factories. A uniform Bill of Materials (BOM) and Bill of Processes (BOP) description is required for this. Smart Factory Web closes this semantic gap with an industry-independent ontology model. Based on the ontology, instances for different industries can be modeled and referenced. In the following, an approach for modeling production processes using Colored Petri Nets is described.

5.4.1. Process Description with Colored Petri Nets

There are several key requirements for a model of a manufacturing process:

• It must be able to describe a flexible network of assets (resources), materials, process steps and intermediate products in a production diagram.
• It should be possible to flexibly assign properties (attributes) to entities.
• The model must be able to handle synchronization and timing in order to describe the scheduling dependencies in a production diagram.
• It must be possible to formulate constraints on process steps such as restrictions on properties of input products.
• The model shall support a modular approach and a hierarchy of submodels. This allows several engineers to work on the same overall model, allows models to be re-used and allows the modeling process to be structured with a top-down or bottom-up approach.
• Models shall be linkable through I/O interfaces.
• A model shall have a formal, mathematical foundation to enable model validation and the deployment of analysis tools to assess the model behavior (e.g., to find deadlocks or to simulate the model execution.

Based on these requirements, Colored Petri Nets (CPN) were selected as a modeling framework [18]. The discrete event graphical modeling language CPN combines Petri Nets and the programming language ML. Petri Nets were originally conceived to model concurrency in distributed systems on the basis of “tokens” flowing along arcs through a network of places and transitions. Arcs are connections from places to transitions or vice versa. A transition of a Petri Net may fire (i.e., execute) if it is enabled, i.e., there are sufficient tokens in all of its input places. When the transition fires, it consumes the required input tokens, and creates tokens in its output places. CPN extends the basic Petri Net concept by allowing complex data objects called colors to be used as tokens and the transitions to realize arbitrary defined mappings of the input tokens onto the output tokens, including a transformation of the colors (Figure 6). The functions to generate the output colors as well as the specification of constraints on when a transition is enabled are defined in the language ML, operating on colors.

CPN conforms to the ISO standard for high-level Petri Nets [19]. CPN has been applied to model many systems ranging from communication protocols and data networks up to business processes and workflows, as well as automatic control and manufacturing systems. A CPN model is executable and can thus be used to simulate the system under study. The built-in language ML allows arbitrary information structures to be modeled. There is a formal definition of syntax and semantics allowing a CPN to be analyzed in depth. The concept of time is covered too, thus enabling the modeling of durations for the execution of transitions.

CPN has been implemented in the free software CPN Tools (http://cpntools.org/, accessed on 15 July 2021). The tool provides a graphical editor for the modeling and simulation of a CPN. CPN Tools supports hierarchical modeling, whereby transitions can be broken down into sub-transitions with associated places and arcs. CPN was combined with AI methods for multi-agent manufacturing scheduling [20]. Moreover, process mining has been carried out based on CPN (discovering CPN from event logs) as in [21]. In summary, CPN provides a rich and flexible modeling environment to describe process diagrams and supply chains.

Figure 7 shows an example CPN model for the production of computer mice. Not all aspects of computer mouse manufacturing are included, but a representative subset to illustrate the approach with a flexible level of detail. In this case, we have two hierarchies of transitions, whereby the top level, ElectronicsManufacturing, is a container transition for the following transitions:

• SolderingBrazing: to join the component products LED, Capacitor, ElectronicCapacitor, USBcable, Switch, RotaryEncoder, Sensor, Lens and SMD (Surface Mounted Device) using SolderingWire and SolderingPaste.
• SMD_Manufacturing: to make an SMD from the input products SMDcapacitor, BlankConductorBoard and resistance.
• 3D_Printing: to produce the mouse Housing from plastic with a set price and color.
• Assembling: to assemble the Scroller, ElectronicPart and Housing for the final product ComputerMouse.

The production process modeled in Figure 7 provides the basis for the search for factories and factory combinations (supply chains).

5.4.2. Search for Factories and Factory Combinations (Supply Chains)

The search for capabilities, production and process steps (Bill of Process BOP) is becoming increasingly important for industrial production marketplaces. Complex, mostly in-house production processes could thus be planned and coordinated across factory boundaries. In addition, collaboration along the entire value chain can be improved and optimized.

The SFW platform provides a web service interface for searching for factories and factory combinations (supply chains) for the required production process.

Figure 8 shows the search flow between a requester, a broker and a provider. Service requesters submit a search request to the SFW platform via the GUI or via web service. The SFW platform processes the request and sends the search result back to the service requester. The goal of the search is to find all factories and factory combinations (supply chains) that offer the required capabilities/production steps. The result can be individual factories or factory combinations (supply chains) that fulfill the entire production process. JSON is used to define the search query and the search result. The search query is specified in Figure 9 and is based on the defined data model in Figure 5.

The search query enables the search for capabilities and therefore also for production and process steps.

• Capability (of an asset) is described in terms of its input and output products and their respective properties, and/or in terms of how the product can be produced. The capability concept enables the modeling of process steps (BOP Bill of Process, e.g., manufacturing processes for the production of a product). The capability description is comprised of the three sections covering (1) the properties of the production process itself, (2) the input products and their properties and (3) the output products and their properties.
• Product: The product structure (BOM Bill of Material) for both input and output products.
• Property: The property concept is used to describe capabilities and products in more detail.

The search is started via the SFW search interface by submitting a search query. The search looks for all factories and factory combinations (supply chains) that fulfill the capabilities/production steps defined in the search query. The search procedure is conducted in three steps as follows:

• Search for factories that possess the requested capabilities: For each capability or process step searched, a list of all factories is generated that possess this capability, including constraints regarding properties and input/output products, or that can execute the production step.
• Generate Cartesian product: Then, the Cartesian product of these factory sets is generated to obtain all possible factory combinations (supply chains).
• Merge factory combinations: In the last step, these supply chains are merged once again. Thereby, factories with several capabilities are identified and the supply chain is simplified (see Figure 10).

5.4.3. Search Result

Figure 11 shows the search result specification in Smart Factory Web. The search result is based on the data model defined in Figure 5. The search returns a set of supply chains as a result. Supply chains consist of one or more assets. An asset is a factory or part of the factory equipment hierarchy, as defined in [17]. In the context of SFW, an asset can be a supplier for another factory. In this section, the focus was on the search for factories and factory combinations (supply chains), and for this reason an asset is considered as a factory.

The search result returns the factories (assets) of a supply chain, the capabilities of the individual factories, the processed input products, the generated output products, precise property descriptions of the products and the matching capabilities. Data objects of the search result are:

• Asset data: unique ID, name, semanticID, description, capabilities;
• Capability data: unique ID, name, semanticID, description, properties, products (input/output);
• Product (input/output) data: unique ID, name, semanticID, description, properties;
• Property data: unique ID, name, semanticID, value or value range (minValue, maxValue), unit of measure.

Figure 12 shows an abstract example of a search result in SFW. The possible result data (return values) of the search are defined in the search result specification (Figure 11). The search result in Figure 12 shows two supply chains.

• The first supply chain consists of three factories (Factory 1–3) to fulfill the required capabilities (Cap1, Cap2, Cap3, Cap4) together. Factory 2 executes two production steps (Cap2, Cap3). Factory 1 and 3 execute one production step.
• The second supply chain consists of four factories (Factory 1–4) to fulfill the required capabilities (Cap1, Cap2, Cap3, Cap4) together. Each factory executes one production step.

5.5. Supply Chain and Supply Network Modelling

The transparency and management of supply chains and entire supply networks is of great importance for companies. The COVID-19 pandemic in particular has shown how vulnerable supply chains can be and how quickly supply bottlenecks can occur. In addition to the avoidance of supply failures, supply chain laws may mandate the transparent description of supply chains.

The German Federal Ministry for Economic Cooperation and Development (BMZ) and the German Federal Ministry of Labor and Social Affairs (BMAS) have produced new legislation for this purpose. The Supply Chain Act will come into force on 1 January 2023, and will obligate companies (depending on the number of employees) along the supply chain to comply with safety, environmental and human rights standards and to create monitoring opportunities [22].

For the prevention of supply chain disruption, the resilient development of supply networks, and the verification of safety, environmental and human rights standards, the entire supply chain must be described and monitored transparently. Flexible, standardized information management systems are needed to transparently describe and monitor supply chains. The SFW platform enables the modeling and visualization of supply chains. Figure 13 shows the supply chain interface of SFW.

The SFW platform enables map-based and tabular visualization of individual supply chains and entire supply networks. The supply chain interface enables the import of supply chains in JSON format via the web interface of the SFW platform. Using the standardized data format JSON, supply chains can be described in a structured and language-independent way [23].

In addition, the SFW platform enables the description and modeling of supply chains via web forms. Supply chains in SFW are modeled according to the product structure (Bill of Materials BOM). Figure 14 shows an example of the product structure of a computer mouse. The computer mouse consists of a scroll wheel, a printed circuit board and other products/components. The printed circuit board in turn is equipped with an LED, a capacitor and other components. The product structure of the computer mouse can thus be broken down to the respective raw materials.

Starting from the top product in the supply chain, the product and supplier structure is broken down to the individual raw materials and raw material suppliers. The entire product and supplier structure from the original equipment manufacturer (OEM) to the individual raw material suppliers (Tier n) can thus be mapped. Figure 15 shows the supplier structure of the computer mouse from Figure 14.

The supplier structure of the computer mouse manufacturer can be broken down transparently with the aid of the product structure in Figure 14. The computer mouse manufacturer (OEM) is supplied with scroll wheels, printed circuit boards and other components by its direct suppliers. The manufacturer of printed circuit boards (Tier 1), in turn, is supplied with LEDs and capacitors by its direct suppliers. The manufacturer of capacitors (Tier 2) is supplied with aluminum and other raw materials.

5.6. Visualization of Supply Networks and Supply Chains

Figure 16 shows the entire supply network of a computer mouse. The SFW platform visualizes supplier networks on a map. Suppliers are displayed on the map according to their location. A distinction between active and inactive suppliers is possible. Additionally, supply chain interruptions and supplier failures can be visualized.

Figure 17 shows the supply chain of the computer mouse example in a table. All products, sub-products, components and raw materials can be broken down and displayed along the entire supply chain. The computer mouse consists of an injection-molded bioplastic housing, feet, a scroll wheel, a USB cable and a printed circuit board equipped with capacitors, encoders, sensors, LEDs and other components. The individual components are shown in the table according to the product structure. The table also shows possible supplier risks in the entire supply chain.

In this way, a possible production failure in the supply chain can be indicated. The red line of the table (Figure 17) shows the production downtime of the encoder supplier. In addition to the supply chain interruptions, the production status and product availability can be displayed. The SFW search function enables the search for alternative suppliers. Alternative suppliers can then be integrated into existing supply chains. The SFW platform thus enables a fast response to risks such as production and supply chain interruptions.

5.7. Trustworthiness

Sharing data between partners in a marketplace is a challenging task, especially when it comes to critical factory production data. While customers want as much information as possible, manufacturers are reluctant to share data with unknown partners. An important question is how to connect factories to share data reliably and securely by ensuring that data owners can choose how their data are used and distributed.

SFW is a marketplace, where factory owners offer their production capabilities to customers worldwide. For example, the factory owner can share information about their product and production capabilities with verified SFW customers. The customers in turn can look for factories to handle the specified order request in the SFW search. Additional sensitive information such as price limits, time requirements and supply-chain-based risks can be included in the search. To take this sensitive information into account and thus to ensure trustworthiness in dynamic marketplace scenarios, there is a need to attach the SFW to a trusted data space that ensures data sovereignty, e.g., data usage control. The technological means for this are security gateways, e.g., trusted connectors [16]. The increased trust will create a better environment for sustaining supply chain relationships and for reducing risks and uncertainty (https://www.bdva.eu/sites/default/files/BDVA_SMI_Whitepaper_2020.pdf, accessed on 15 July 2021).

6. Evaluation

The following two tables describe if, and if yes, to which degree the SFW architecture and platform fulfills the non-functional (

Table 7. Smart Factory Web in relation to the non-functional requirements in the platform economy.

Number	Requirement	SFW Fulfillment
NFR01	Interoperability with other industrial marketplaces and software systems (support for federations)	+
NFR02	Applicability to new industrial domains and sub-domains	p
NFR03	Openness in the sense of supporting international and national standards to avoid vendor lock-in and follow future technological trends	+++
NFR04	Adaptability to new business models	+
NFR05	Scalability of user, data and app management	++
NFR06	Security to protect company data from unauthorized access and assure its integrity	++
NFR07	Data Sovereignty to maintain control over the complete processing chain of data and also the independent decision on who is permitted to have access to it	+
NFR08	Extensibility to support new types of production assets(e.g., virtual assets such as production-related services)	p

Legend: +++—full fulfillment, ++—mainly fulfilled, +—partial fulfilment with limitations, p—possible and in planning, -—not in scope.

) and functional (

Table 8. Smart Factory Web in relation to the functional requirements in the platform economy.

No	Requirement	SFW Fulfillment
FR01	Provision of a flexible, domain-independent data model to describe production assets, capabilities and properties, including supply chains characteristics	+++
FR02	Registration of factories based on the capability model and open standards (e.g., of the Platform Industrie 4.0) to describe the production capabilities and capacities of the factories	+++
FR03	Search for factories, factory assets and factory combinations (supply chains) for a required production process	+
FR04	Matchmaking between production process description of a production request and the capabilities and capacities of registered factories	+
FR05	Ranking of search results according to user preferences	p
FR06	Query the availabilities of factories and factory assets in (near) real time, i.e., respecting the time constraints of the use case	+
FR07	Generate, manage, query and analyze supply chains.	+
FR08	Visualization of shop floor data (machines, etc.)	+++
FR09	Visualization of supply chains/supply networks	+++
FR10	Detection and visualization of supply chain interruptions	p
FR11	Defining redundant supplier structures	+
FR12	Validation of quality/sustainability criteria along the supply chain (e.g., carbon footprint)	-
FR13	Provision of additional functionalities for the use of the marketplace via an app store	+
FR14	Provision of an open, standardized interface for connecting external platforms/marketplaces (federations)	++
FR15	Provision of a means to download software applications from an app store to enhance or tailor the functionality	p
FR16	Provision of means to adapt the information model and functionality of the service broker to new contexts and situations	p

Legend: +++—full fulfillment, ++—mainly fulfilled, +—partial fulfilment with limitations, p—possible and in planning, -—not in scope.

) requirements as claimed for an open marketplace in the platform economy in Section 2.

7. Validation in International Smart Factory Markets

7.1. Negotiation Automation Platform in Japan

NEC Corporation is developing the Negotiation Automation Platform (NAP). The NAP enables flexible automated negotiation of detailed trading conditions and business counterparts matching across manufacturing supply chains by employing new AI-based negotiation technologies. Automatic negotiation on conditions of trading products is beneficial for both buyers and sellers. It enables buyers to satisfy their needs through flexibly expressing their procurement requirements, and enables sellers to expand opportunities for orders and profits by making full use of assets. Additionally, automatic negotiation enables on-demand shared transport services which help factories:

• To adapt their transport systems to the current business situation, respectively;
• To reduce logistics costs;
• To avoid redundant traffic and reduce the total traffic amount in society.

NAP and its integration with the SFW was proposed and accepted as an IIC testbed. NAP utilizes the services of the SFW platform to find negotiation counterparts. NAP users search for smart factories with specified capabilities on SFW. Once the users have achieved agreement of business conditions with the counterparts through NAP, then, they can share operational information during manufacturing execution by further SFW platform services. NAP and SFW complement each other in connected and self-orchestrated supply chains.

7.2. Smart Factory Networks in South Korea

KETI (Korea Electronics Technology Institute) operates the SMIC (Smart Manufacturing Innovation Center) (https://www.demo-factory.kr, accessed on 15 July 2021), which is a demonstration factory for smart factory testbeds. The SMIC also served as an interoperability test environment for plug-and-work methods and modular production processes. The SMIC machines have been registered in the SFW platform by means of their assets and capabilities. In addition, the following applications were developed in order to increase the flexibility and adaptability of the production assets registered in the SFW:

• Process Automation Market: Development and proof of concept of Batch Process Orchestration technology based on an OPC UA information model. It shows how modularity of water treatment processes may be realized by means of OPC UA in order to increase the flexibility and changeability.
• Parts Processing Market: KPI prediction by applying the concept of digital twins to virtual commissioning, e.g., to predict design and engineering accuracy and precision, and to optimize the process and complete the product w.r.t. energy consumption, material usage, time, waste, etc.

Furthermore, the SMIC carries out research on next-generation communication technology for industrial production, e.g., it investigates if Time-Sensitive Networks over wireless communication technology can be applied to production processes to finally replace and surpass existing communication technologies. This would enable quality measurement in real time and improve the production speed and monitoring up to the SFW customer. By means of AI methods, forecasts about product delivery times can be improved to support, e.g., instant quoting in the SFW platform.

7.3. European Project Eur3ka

The global economic impact of the COVID-19 pandemic on the manufacturing sector has been tremendous. At the same time, the manufacturing sector has been a critical part in the response to the crisis. However, the manufacturing sector was not fit enough for this purpose. Eur3ka (EUropean Vital Medical Supplies and Equipment Resilient and Reliable Repurposing Manufacturing as a Service NetworK for Fast PAndemic Reaction) is a H2020 project (https://www.eur3ka.eu/, accessed on 15 July 2021) that will enable more resilient manufacturing networks. Such manufacturing networks could be quickly repurposed and thus will be able to cope in a coordinated manner with peaks of demand associated with outbreaks such as COVID-19.

The quick adaptation of manufacturing lines will be provided through integration of manufacturing capabilities in the SFW platform. One of the key functions of the SFW is to match the manufacturing needs of the medical sectors with the manufacturing capability available globally to meet those needs. This functionality is currently being extended to consider confidential information such as price limits, time requirements and supply chain risks. Since capacity and workload are sensitive data, the manufacturers only allow these data to be used to enhance search requests. IDS is a viable option to technically enforce these usage restrictions.

Additionally, as Eur3ka aims to develop a trusted federation of European and global manufacturing resources, there is a need to federate SFW with platforms offering similar or partially overlapping functionalities. Interoperability and information exchange between autonomous platforms require the use of standards for modeling data and interfaces. In this context, the SFW will be made Plattform Industrie 4.0-compliant, which will ensure understanding of the SFW content and interaction with the SFW.

8. Conclusions and Outlook

The article describes an architectural proposal for marketplaces in the domain of industrial production that follows the paradigms of the platform economy. In contrast to multiple commercial marketplaces for industrial production, this approach is based on principles of openness, i.e., relying upon international standards as much as possible in order to avoid platform vendor lock-ins. As an example, the Smart Factory Web has been presented which originally stemmed from the realization of a testbed of the same name at the International Internet Consortium (IIC). The Smart Factory Web serves both as an architectural blueprint for such endeavors, possibly also for other application domains, and as an example of an experimental marketplace system.

Currently, the topic of service ecosystems, and here production service ecosystems, gains more and more attraction in Europe due to the emergence of the European data infrastructure entitled GAIA-X (https://www.data-infrastructure.eu/GAIAX/Navigation/EN/Home/home.html, accessed on 15 July 2021). This data infrastructure shall basically follow European laws and regulations for data privacy and data sovereignty. Based upon this infrastructure under development, the community of market branches is encouraged to build service infrastructures. GAIA-X makes it possible to offer services of the platform economy, i.e., “xxx as a service”, including the value proposition of data sovereignty. The automotive industry is about to take up and drive this ambition in their Catena-X Automotive Network initiative (https://catena-x.net/en/, accessed on 15 July 2021). The Smart Factory Web architecture is brought in as a validated approach and background to this initiative.