EFFRA Innovation Portal

SKILLPRO | Skill-based Propagation of Plug&Produce-Devices in Reconfigurable Production Systems by AML

01-10-2012

-

30-09-2015

Show more information

Comments UA + First communication protos using REST and Webservices + eCat access through web services + Development of metal works library and electronics works library Number of project results taken-up
AutomationML and OPC UA Result title AutomationML and OPC UA Result description Due to the constant promotion and discussion the idea of combining OPC-UA and AutomationML lead to a new group in the OPC-UA consortium for defining and further developing AutomationML as companion standard

BEinCPPS | Business Experiments in Cyber Physical Production Systems

11-01-2015

-

31-10-2018

: 51 | : 5

Show more information

ICT performance characteristics

Results:

Lombardy Champion - Zero-Hours Quality

Encryption of all Factory-Cloud data channels (HTTPS). Google authentication for Android applications.

Results:

Rhône-Alpes Champion: The Smart Mold

Lombardy Champion - Zero-Hours Quality

Results:

Rhône-Alpes Champion: The Smart Mold

OPC-UA for M2M communication, and NGSI for data publishing on the cloud

Lombardy Champion - Zero-Hours Quality

Results:

Lombardy Champion - Zero-Hours Quality

OPC UA, NGSI

Results:

Lombardy Champion - Zero-Hours Quality

Results:

Lombardy Champion - Zero-Hours Quality

OPC UA Address Space for Testing Stations

Results:

Rhône-Alpes Champion: The Smart Mold

All the information is stored in a single context in the Orion Context Broker.

Results:

Rhône-Alpes Champion: The Smart Mold

Lombardy Champion - Zero-Hours Quality

Results:

Rhône-Alpes Champion: The Smart Mold

The experiment involves the "CPS-ization" of a mechanical piece of equipment used in the plastic injection process: the mold. It will be enabled with sensors to capture the physical properties relevant during the injection process, mainly temperature and pressure. In certain variations of the smart mold, it will also drive electrical actuators to perform in-mold mechanical movements, such as piece ejection or product version-switching. Sensors: -Temperature: MIKROELEKTRONIKA Thermocouple Type-K Glass Braid Insulated -Pressure: KISTLER 6190C Actuators: -Stepper motor: SM2863-5155

Lombardy Champion - Zero-Hours Quality

On the Field level is deployed Whirlpool-specific hardware (Controller and Actuator boards) and software (the Test Executor) that are directly connected to the Product under test.

Results:

Rhône-Alpes Champion: The Smart Mold

The mold is mounted on top of an press machine, which performs the actual raw material conversion and performs the actual injection process. The smart mold communicates with the press to raise pre-configured alerts when the sensors detect abnormal situations, as well as to guide mechanical movements.

Lombardy Champion - Zero-Hours Quality

Online results of Product testing are also used for the early detection of problems in the manufacturing plant.

Results:

Rhône-Alpes Champion: The Smart Mold

The smart mold publishes data to a production manager workstation, which in the context of a factory gathers all the data from all the work cells i.e. injection presses and provided an enterprise-level view of the deployed molds in production.

Lombardy Champion - Zero-Hours Quality

Offline analysis of historical Product testing results can be used to identify inefficiencies of production processes across the Enterprise.

Results:

Rhône-Alpes Champion: The Smart Mold

The Smart Mold, as a true cyber-physical system, publishes data through a cloud infrastructure. In this cloud space, different applications are made available: -Visualization dashboards through widgets, to allow real-time visualization of production data -Data persistence: Store the physical data acquired by the sensors to enable historical analysis -Integration with information systems (ERP/MES): To trigger mainteinance operations for the mold when these are required

Results:

Rhône-Alpes Champion: The Smart Mold

The plastic pieces as a result of the injection process.

Lombardy Champion - Zero-Hours Quality

The system is applied to whole Product items as they leave the assembly line.

Comments UA (factory automation), IEC-61499 (real-time automation), AMQP (messaging), NGSI (publish/subscribe) Main endorsed standards: OPC UA (factory automation), IEC-61499 (real-time automation), AMQP
Lombardy Champion - Zero-Hours Quality Result description It is worth noting that the development of the OPC-UA Address Space used for in Whirlpool experimentation was entirely done by means of the UA Modeler tool, which is a Virtual World component.
OPC-UA Taxon title OPC-UA
Semantic/information interoperability Taxon description For example through APIs, WSDL, RESTFUL, SOAP, OPC UA, WEBSOCKET, ISA 95, ISA 88, IEC 61499
Standards Comments UA (factory automation), IEC-61499 (real-time automation), AMQP (messaging), NGSI (publish/subscribe) Main endorsed standards: OPC UA (factory automation), IEC-61499 (real-time automation), AMQP

AUTOWARE | Wireless Autonomous, Reliable and Resilient ProductIon Operation ARchitecture for Cognitive Manufacturing

01-10-2016

-

30-09-2019

: 60 | : 1

Show more information

ICT performance characteristics

Comment: CPPS validation & verification (CPPS cloudified control performance simulation). Open trusted CPPS

Results:

D4.3a AUTOWARE Open CPPS ecosystem development

Comment: Goal: AUTOWARE will establish and push forward an open CPPS ecosystem, allowing SMEs to access all the different components in order to develop digital automation cognitive solutions for their manufacturing processes. . Leveraging reference heterogeneous communications and networking architecture to support connectivity & data management in CPPS. To allow the interaction and interworking of the heterogeneous communications and networking technologies necessary to support the ubiquitous connectivity of CPPS.

Comment: 5G, WirelessHart

Comment: NFV-Low latency networks.NFV: Network functions virtualization)

Results:

D4.3a AUTOWARE Open CPPS ecosystem development

Results:

D4.3a AUTOWARE Open CPPS ecosystem development

Comment: Cloud & App-ized Control Systems

Comment: Cloud & App-ized Control Systems. Open & Reconfigurable Cells.

Comment: Cloud based planning systems. Dual reality service orchestration.

Comment: Wireless resilient communications (5G & Wirelesshart).

Comments Public-subscribe OPC-UA ; OPC-UA rt.
OPC-UA Taxon title OPC-UA Taxon description OPC Unified Architecture (OPC UA) is a machine to machine communication protocol for industrial automation developed by the OPC Foundation.
Standards Comments Public-subscribe OPC-UA ; OPC-UA rt.

FLEXCELLE | Flexible Nacelle Manufacturing

: 3

Show more information

ICT performance characteristics

Results:

Virtual commissioning

Used as the primary date exchange method for the demonstrator. Links items on the shop floor to the SCADA.

Results:

Virtual commissioning

Reconfigurable assembly systems

Integrated Artificial Intelligence

Results:

Virtual commissioning

Used as the primary date exchange method for the demonstrator. Links items on the shop floor to the SCADA.

Integrated Artificial Intelligence Result description The integrated digital twin system of FA3D2 simplifies the gathering and contextualising of data via an OPC UA-based service bus.

DIGICOR | Decentralised Agile Coordination Across Supply Chains

01-10-2016

-

30-09-2019

: 42

Show more information

ICT performance characteristics

Comment: DIGICOR will develop holistic security and governance mechanisms to ensure the access, data transfer and collaborations are protected at the platform level. Some of the security mechanisms being developed in the project include: Advanced pairing-based cryptography (e.g., Attribute-Based Encryption-ABE), Semantic multi-aspect access and usage control, Security-aware workflow verification & adaptation for inherent compliance, Integration of security protocols with IPR management and adaptations of DRM technologies for document management

Results:

D5.8: Data access API & Reference data store (Final Release)

Comment: DIGICOR applications are developed as standalone plug-and-play tools with dedicated interfaces. External applications (e.g. production planning, schedulling, workflow management etc) can also be deployed on DIGICOR toolstore

Comment: Docker based application packaging and deployment is adopted in DIGICOR

Comment: Communication with middleware is supported by open data model to be developed.

Comment: External applications can communicate with OPC-UA based middleware (subject to authentication etc) to ingest data e.g. from factories

Comment: DIGICOR Toolstore can host external/standalone applications

Results:

D5.8: Data access API & Reference data store (Final Release)

D5.10 DIGICOR Data Models Implementation

Comment: Gateway (interfaces with external applications, built on top of middleware.

Comment: The communication middleware in the DIGICOR platform will be based on OPC-UA standard. In order to facilitate the flow of data to and from the middleware, the project will develop Data (harmonisation and transformation) Maps. The Data Maps will be offered as microservices to address the semantic and syntactic interoperability issues. In addition, standardised service interfaces will be defined to allow the discovery and enactment of services within the DIGICOR Platform.

Results:

D5.10 DIGICOR Data Models Implementation

Results:

D5.8: Data access API & Reference data store (Final Release)

Comment: KeyCloak - based on Standards (OpenID Connect, OAuth 2.0 and SAML 2.0)

Comment: KeyCloak based Identity and Access Management of platform of DIGICOR Platform

Comments In addition to OPC UA, the project will reuse existing results/ontologies/data models for semantic interoperability coming from different standards (OASIS, etc.)
OPC-UA Taxon title OPC-UA
Semantic/information interoperability Taxon description For example through APIs, WSDL, RESTFUL, SOAP, OPC UA, WEBSOCKET, ISA 95, ISA 88, IEC 61499
Standards Comments In addition to OPC UA, the project will reuse existing results/ontologies/data models for semantic interoperability coming from different standards (OASIS, etc.)

FA3D2 | Future Automated aerospace Assembly Demonstrator project: Phase 2

: 4

Show more information

ICT performance characteristics

Results:

Virtual commissioning

Used as the primary date exchange method for the demonstrator. Links items on the shop floor to the SCADA.

Results:

Virtual commissioning

Reconfigurable assembly systems

Integrated Artificial Intelligence

Results:

Virtual commissioning

Used as the primary date exchange method for the demonstrator. Links items on the shop floor to the SCADA.

Integrated Artificial Intelligence Result description The integrated digital twin system of FA3D2 simplifies the gathering and contextualising of data via an OPC UA-based service bus.

MUSIC | MUlti-layers control&cognitive System to drive metal and plastic production line for Injected Components

01-09-2012

-

31-08-2016

: 13 | : 6

Show more information

ICT performance characteristics

Comment:

OPC_UA has been intensively applied in the Data_driven Digital Twin of existing production line

Comment:

OPC_UA has been intensively applied in the Data_driven Digital Twin of existing production line

Comment:

The equipment and devices are sensorized to be deeper monitored

Comment:

Manufacturing cell is monitored with data acquisition from any level.

Comment:

All stages of production line are connecteted to the Data-Driven Digital Twin platform

Comment:

All different production lines and plants can be monitored wiht the same platform because it is felxible and scalable.

Comment:

Data-Driven Digital Twin enables the collaboration between OEM and Suppliers

Comments Greggio: Digital Transformation to Foundry 4.0, 73WFC, 25 Sept2018 OPC-UA Standards and standardisation Standards according to SDOs Standards OPC_UA has been intensively applied in the
Monitoring System HW and SW Result description New measurement equipment replacing the old system featuring OPC-UA data transfer
OPC-UA Taxon title OPC-UA Taxon description OPC Unified Architecture (OPC UA) is a machine to machine communication protocol for industrial automation developed by the OPC Foundation.

FA3D | Future Automated Aerospace Assembly Demonstrator Project

: 3

Show more information

ICT performance characteristics

Results:

Manufacturing Service Buses for Data Interoperability

OPC UA (Kepware) – Many devices could not interface directly with the service bus, so OPC UA was used to extract data and publish it to the service bus.

Results:

Metrology-integrated Robotics

Manufacturing Service Buses for Data Interoperability

ATS Bus - Enabled a single, common service bus for data exchange between the PLCs and other high level components of the system, including a SCADA system. Used a broker-based publish-subscribe approach to decouple the physical sources and destinations of the data to facilitate reconfigurability.

Nservicebus - The underlying technology which enabled the ATS Bus to exchange data.

OPC UA (Kepware) – Many devices could not interface directly with the service bus, so OPC UA was used to extract data and publish it to the service bus.

Results:

Manufacturing Service Buses for Data Interoperability

OPC UA (Kepware) – Many devices could not interface directly with the service bus, so OPC UA was used to extract data and publish it to the service bus.

Results:

Manufacturing Service Buses for Data Interoperability

B2MML – Business to Manufacturing Mark-up Language. Data standard used to define the process (i.e. the set of operations to be carried out by the cell for each unique product), what resources are required for each process, the materials needed and more. The full process would be designed by engineers, and then the SCADA would break the ‘master’ B2MML process representation into sub-processes and send these to the resources via the service bus. These would then trigger the start of processes by the PLCs.

Results:

Manufacturing Service Buses for Data Interoperability

B2MML – Business to Manufacturing Mark-up Language. Data standard used to define the process (i.e. the set of operations to be carried out by the cell for each unique product), what resources are required for each process, the materials needed and more. The full process would be designed by engineers, and then the SCADA would break the ‘master’ B2MML process representation into sub-processes and send these to the resources via the service bus. These would then trigger the start of processes by the PLCs.

VIEWS | Validation and Integration of Manufacturing Enablers for Future Wing Structures

: 1 | : 2

Show more information

ICT performance characteristics

Results:

Manufacturing Service Buses for Data Interoperability

OPC UA (Kepware) – Many devices could not interface directly with the service bus, so OPC UA was used to extract data and publish it to the service bus.

Results:

Metrology-integrated Robotics

Manufacturing Service Buses for Data Interoperability

ATS Bus - Enabled a single, common service bus for data exchange between the PLCs and other high level components of the system, including a SCADA system. Used a broker-based publish-subscribe approach to decouple the physical sources and destinations of the data to facilitate reconfigurability.

Nservicebus - The underlying technology which enabled the ATS Bus to exchange data.

OPC UA (Kepware) – Many devices could not interface directly with the service bus, so OPC UA was used to extract data and publish it to the service bus.

Results:

Manufacturing Service Buses for Data Interoperability

OPC UA (Kepware) – Many devices could not interface directly with the service bus, so OPC UA was used to extract data and publish it to the service bus.

Results:

Manufacturing Service Buses for Data Interoperability

B2MML – Business to Manufacturing Mark-up Language. Data standard used to define the process (i.e. the set of operations to be carried out by the cell for each unique product), what resources are required for each process, the materials needed and more. The full process would be designed by engineers, and then the SCADA would break the ‘master’ B2MML process representation into sub-processes and send these to the resources via the service bus. These would then trigger the start of processes by the PLCs.

Results:

Manufacturing Service Buses for Data Interoperability

B2MML – Business to Manufacturing Mark-up Language. Data standard used to define the process (i.e. the set of operations to be carried out by the cell for each unique product), what resources are required for each process, the materials needed and more. The full process would be designed by engineers, and then the SCADA would break the ‘master’ B2MML process representation into sub-processes and send these to the resources via the service bus. These would then trigger the start of processes by the PLCs.

FAR-EDGE | Factory Automation Edge Computing Operating System Reference Implementation

01-10-2016

-

30-10-2019

: 70 | : 17

Show more information

ICT performance characteristics

Results:

Secure State Sharing and Intelligent Reconfiguration for Edge Computing - M15 release

Comment: According to the RAMI 4.0 architecture, the “standard” way for Industrie 4.0 platforms to integrate legacy equipment (or any other kind of legacy “object”, including software components) into will be to encapsulate them inside an ad-hoc Administration Shell wrapper, which will expose them as I4.0 Components. The I4.0 interface specification has not been published yet, but a key enabling technology will probably be OPC UA, used as both a communication protocol and a data meta-model. In FAR-EDGE, OPC UA will be one of the field communication technology supported.

Results:

CPS Data Model Architecture - M24 release

Comment: The Platform is a composition of self-contained modules. Business logic for automation and analytics is packaged as Docker images.

Comment: The Plaform defines its own Open API

Comment: AutomationML, SenseML, OPC UA.

Comment: The FAR-EDGE architecture defines a protocol abstraction layer (the “connectivity middleware” box in the diagram provided here – this name is provisional) to decouple the field from its Edge Computing infrastructure: this is where OPC UA compatibility is going to be introduced.

Comment: The system blueprint is the FAR-EDGE RA. After having defined the requirements and the constraints for each block of the RA, a thorough analysis of the SotA has been done, which led to the identification of some existing software components meeting the specs. We then identified the gaps that the project will need to fill-in: not surprisingly, these where all the key enabling technologies, like the distributed ledger. However, hardly anything is going to be built totally from scratch in FAR-EDGE. The distributed ledger, for example, will be a customization of a generic, open source Blockchain platform (Hyperledger Fabric). Following the high-level functional decomposition defined in the FAR-EDGE RA, three Open APIs will be exposed by the Cloud layer of the FAR-EDGE Platform: Automation, Virtualization and Analytics. Automation will provide endpoints to monitor, control and manage automation workflows deployed on the Edge layer. Virtualization will create hooks for external simulation tools that need to read and manage factory models deployed on the Cloud layer (that are kept in-sync with the real world by the lower layers). Analytics will allow to manage distributed data analysis processes running on the Edge layer, and to collect aggregated results.

Comment: TBD (OpenID Connect is the candidate technology for securing the Open API)

Comment: New Generation Access Control (NGAC) framework for the specificication and enforcement of access polocies

Comment: Relevant architectures for FAR-EDGE are Platform Industrie 4.0 (RAMI 4.0), Industrial Internet Consortium (IIRA), OpenFog Consortium (OpenFog RA). We will use the 3D coordinate system from RAMI 4.0 to map the elements of the FAR-EDGE Platform to concepts that are commonly understood and agreed on within the Industrie 4.0 community. We are also taking care that the FAR-EDGE Platform implementation will be compatible with future Industrie 4.0 compliant equipment – in particular I4.0 Components – by supporting OPC UA as the main protocol for field communication. Regarding IIRA and OpenFog RA, in the FAR-EDGE RA we are adopting a key architectural pattern included in both of them (with different names): a layered approach that leverages peer-to-peer communication in each layer to decentralize control. The most visible trait of the FAR-EDGE reference architecture is its partitioning into horizontal layers having different scopes – i.e., in bottom-up order: Fog (field, shopfloor), Edge (plant), Cloud (enterprise, supply chain). This pattern in inspired from a similar one in IIRA, called Layered Databus. However, in FAR-EDGE there is no “databus” included in each layer, but rather an additional layer called the Ledger, positioned between the Edge and the Cloud ones. Its role is to coordinate the execution of distributed processes running on Edge Gateways. The horizontal partitioning of the RA is driven by technical concerns (e.g., where software components are deployed, who are the stakeholders of their implementation). There is also a vertical partitioning, though, which is orthogonal to the horizontal one. This is a high-level functional decomposition which identifies three functional scopes: Automation, Virtualization and Analytics (more on that in the API section below).

Comments In FAR-EDGE, OPC UA will be one of the field communication technology supported.
Protocol interoperability of OPC UA in service oriented architectures Result title Protocol interoperability of OPC UA in service oriented architectures
Interoperability (ICT) Comments In FAR-EDGE, OPC UA will be one of the field communication technology supported.

Z-BRE4K | Strategies and Predictive Maintenance models wrapped around physical systems for Zero-unexpected-Breakdowns and increased operating life of Factories

01-10-2017

-

31-03-2021

: 39 | : 3

Show more information

ICT performance characteristics

Comment:

Α Web API will return semantic data. The communication interface is through the SPARQL query engine. Z-BRE4K ontology is implemented with the Open Semantic Framework (OSF), an integrated software stack using semantic technologies for knowledge management. Furthermore, JSON formatted data from the shop floor is transferred through a MQTT broker, to be finally stored in I-LiKe machines internal data repository. IDS connectors are used to transform data into the NGSI format, move the data to the ORION context broker to be finally consumed by other applications. Also, the Quality Information Framework (QIF) standard guarantees interoperability since it defines an integrated set of information models that enable the effective exchange of metrology data throughout the entire manufacturing quality measurement process – from product design to inspection planning to execution to analysis and reporting. OpenCPPS (part of AUTOWARE) will provide support for selected mainstream communication protocols and will define the proper interfaces for other communication protocols to be plugged-in.

Comment:

Orion is a C++ implementation of the NGSIv2 REST API binding developed as a part of the FIWARE platform that allows the management of the entire lifecycle of context information including updates, queries, registrations and subscriptions. It is an NGSIv2 server implementation to manage context information and its availability allowing subscription to context information so when some condition occurs notifications are sent. The Industrial Data Space foster secure data exchange among its participants, while at the same time ensuring data sovereignty for the participating data owners. The architecture of the Industrial Data Space does not require central data storage capabilities but follows a decentralized approach, meaning that data physically remain with the respective data owner until they are transmitted to a trusted party. Thus, the Industrial Data Space is not a cloud platform, but an architectural approach to connect various, different platforms.

Comment:

Ontology-based data integration is part of the Z-BRE4K solution. Ontology effectively combines data and/or information from multiple heterogeneous sources. The ontology semantics used by SPL program is described through OWL. OWL follows the RDF syntax, so SPARQL is suitable for seamlessly querying the ontology defined by OWL. SPARQL will be used as the transformation language for converting Semantic data to corresponding syntax data. IDS connectors are used in Z-BRE4K to guarantee the interoperability among the various components that are not part of the Industrial Data Space. Part of connectors functionality is to transform data to/from NGSI format data in order to be shared by the ORION context broker.

Comment:

Z-BRE4K ontology contains information about all Z-BRE4K relevant data (metadata), linked in a way described by a controlled, shared vocabulary. The data relationships are part of the data itself, in one self-describing information package that is independent of any information system. In simple terms, this means that data from various sources can be easily harmonised. The shared vocabulary, and its associated links to an ontology, provide the foundation and the capabilities of machine interpretation, inference, and logic.

Comment:

The Z-Bre4k solution is based on the blackboard architectural model. This model is mainly an artificial intelligence approach, where a common knowledge base, the "blackboard", is iteratively updated by a diverse group of specialist knowledge sources, starting with a problem specification and ending with a solution. Each knowledge source updates the blackboard with a partial solution when its internal constraints match the blackboard state. In this way, the specialists work together to solve the problem. The blackboard model was originally designed as a way to handle complex, ill-defined problems, where the solution is the sum of its parts. The blackboard component acts as a central repository system. The rest of the software applications (components) act independently at the common data structure stored on the blackboard, they respond on changes and create new reactions according to changes. Interaction between components is implemented via the blackboard.

Comment:

Z-BRE4K ontology supports real-time communication capabilities, by providing an agreement among a shared conceptualization, an explicit formal specification and in-between-relations of objects to support the predictive maintenance domain and data classification. Real-time data is gathered from the shop-floor and sent through the MQTT broker to be consumed by the solution’s prediction software applications in order to predict and provide suggestions. I-Like Machines provide a visualization UI and provide a real-time monitoring of relevant variables and comparison with meaningful thresholds.

Comments OPC UA supports two protocols. The binary protocol is opc.tcp://Server and http://Server is for Web Service. Otherwise OPC UA works completely transparent to the API.
OPC-UA Taxon title OPC-UA
Semantic/information interoperability Taxon description For example through APIs, WSDL, RESTFUL, SOAP, OPC UA, WEBSOCKET, ISA 95, ISA 88, IEC 61499
Information and communication technologies Comments OPC UA supports two protocols. The binary protocol is opc.tcp://Server and http://Server is for Web Service. Otherwise OPC UA works completely transparent to the API.
Standards Comments OPC UA supports two protocols. The binary protocol is opc.tcp://Server and http://Server is for Web Service. Otherwise OPC UA works completely transparent to the API.

OPeraTIC | Boosting the adoption of Ultrashort Pulsed Laser large scale structuring with an agile, dexterous and efficient manufacturing platform

01-10-2022

-

31-03-2026

Show more information

Description Finally, OPeraTIC proposes an I4.0-compliant platform for systematic data exchange and integrated bidirectional communication (Automation-ML and OPC-UA standards) between real environment and its digital

LAY2FORM | Efficient Material Hybridization by Unconventional Layup and Forming of Metals and Composites for Fabrication of Multifunctional Structures

01-10-2017

-

30-09-2021

: 9

Show more information

Off-line programming of a flexible and adaptive production line for composite-metal multi-material manufacturing based on OPC-UA communication Result title Off-line programming of a flexible and adaptive production line for composite-metal multi-material manufacturing based on OPC-UA communication

DIMOFAC | Digital Intelligent MOdular FACtories

01-10-2019

-

31-03-2024

: 18

Show more information

ICT performance characteristics

An OPC UA Model of the Skill Execution Interaction Protocol for the Active Asset Administration Shell Result title An OPC UA Model of the Skill Execution Interaction Protocol for the Active Asset Administration Shell

UPTIME | UNIFIED PREDICTIVE MAINTENANCE SYSTEM

01-09-2017

-

31-08-2020

: 39 | : 3

Show more information

ICT performance characteristics

Comment:

Open Platform Communication Unified Architecture (OPC-UA) is considered for UPTIME platform and for modular edge data collection and diagnosis of UPTIME_SENSE component.

Comment:

The UPTIME platform is built upon the predictive maintenance concept, the technological pillars (i.e. Industry 4.0, IoT and Big Data, Proactive Computing) and the existing baseline tools (i.e. USG, preInO, PANDDA, SeaBAR, DRIFT) resulting in a unified information system for predictive maintenance. The extended UPTIME baseline tools (SENSE, DETECT, PREDICT, DECIDE, ANALYZE, FMECA, VISUALIZE) will address the various steps of the unified predictive maintenance approach and will incorporate interconnections with other industrial operations related to production planning, quality management and logistics management.

Comment:

Open Platform Communication Unified Architecture (OPC-UA) is considered for UPTIME platform and for modular edge data collection and diagnosis of UPTIME_SENSE component.

Comment:

To ensure secure access, the UPTIME Platform offers appropriate authorization and authentication mechanisms. These are based on the JWT technology and are implemented by using the Spring Security framework. Currently, JWT is used to ensure a secure log-in; as components are iteratively integrated. JWT will also be used to ensure secure communications between components.

Comment:

The UPTIME conceptual architecture was designed according to the ISO/IEC/IEEE 42010 “System and software engineering – Architecture description” and mapped to RAMI 4.0 in order to ensure that it can be represent predictive maintenance in the frame of Industry 4.0.

The UPTIME vision converges and synthesizes predictive maintenance, proactive computing, the Gartner’s levels of industrial analytics maturity and the ISO 13374 as implemented in MIMOSA OSA-CBM in order to create a consistent basis for a generic predictive maintenance architecture in an IoT-based industrial environment. In this way, the Operational Technology and the Information Technology can also be converged in the context of Industry 4.0.

Comment:

One of the main functionalities of UPTIME Platform is the batch data analytics implemented by UPTIME_ANALYZE component to analyse maintenance-related data from legacy and operational data and UPTIME_FMECA component that provides estimation of possible failure modes. The interoperability interfaces with UPTIME End-Users' (e.g. Whirlpool) legacy systems are defined, specified and developed according to latest practices and standards for APIs.

Comments OPC-UA Standards and standardisation Standards according to SDOs Standards Open Platform Communication Unified Architecture (OPC-UA) is considered for UPTIME platform and for modular edge data
OPC-UA Taxon title OPC-UA Taxon description OPC Unified Architecture (OPC UA) is a machine to machine communication protocol for industrial automation developed by the OPC Foundation.

SeCoIIA | Secure Collaborative Intelligent Industrial Assets

01-12-2019

-

31-05-2022

: 28 | : 4

Show more information

ICT performance characteristics

Experimental Remote Attestation over OPC UA Protocol Result title Experimental Remote Attestation over OPC UA Protocol

SO-PC-PRO | Subject-Orientation for People-Centred Production

01-10-2013

-

30-09-2016

: 7 | : 5

Show more information

ICT performance characteristics

Seamless process management across the IEC 62264 control hierarchy Result description Extensions include interfaces and model transformations using industrial automation standards (OPC UA, PLCopen XML, B2MML).

Z-Fact0r | Zero-defect manufacturing strategies towards on-line production management for European factories

01-10-2016

-

31-03-2020

: 35 | : 1

Show more information

ICT performance characteristics

Comment:

Implementation of security mechanism on the Z-Fact0r platform components, to achieve security. The basic architecture provides authorization and authentication as a means of deploying a secure system architecture.

Comment:

Difficulties in having access to machines/systems in the shopfloor for end users’ internal security policies was mitigated with the shopfloor machines/systems interface that is carried out by implementing security measures where different options to avoid direct access to machines through the company network have been investigated (e.g. separate network, mirror DB,…)

Comment:

Difficulties in setting up the initial data collection infrastructure on the pilot sites was mitigated through the very careful data collection infrastructure selection where end users have been constantly assisted to set up the best approach to transfer data to Z-Fact0r platform, taking into consideration the internal security policies of the companies.

Comment:

The secure connection are encrypted by two types of authentication:

With username and password
With X.509 Certificate, the client presents his certificate to the broker during the TLS handshake.

Comment:

Z-Fact0r system is a distributed system by desing. The connections between the components and the data flow is authorized by the iLike machine in order the system to maintain all security aspects.

Comment:

X.509 Certificate for the client certification and TLS handshakes between the Z-Fact0r components and the iLike machines

Comment:

SSL (Secure Sockets Layer) is a cryptographic protocol to provide communications security and ensure privacy and data integrity between two or more communicating computer applications.
OpenSSL is an open-source software library that contains an implementation of the SSL protocol used by NGINX (web server) to provide API over HTTPS.

Comment:

Data communication between components is essential for the project. End users create data on their shop floor with embedded sensors on the machines, new integrated sensors developed for the project. All these data is propagated in the system with data communication protocols, such as HTTP and AMQP, creating a data stream process in the system. Interoperability between the data communication protocolos and brockers is crucial for a successful result of the data communication of the system. Various data sources work together and use different communication protocols. As a result, all these components and protocols should seamlessly work and their interoperability is what helps them. A message brocker was developed for the project, based on AMQP for data communication. In the initial phases of the project, there were also RESTful APIs that helped in the initial development of the components.

Comment:

Z-Fact0r components were developed by different technical providing partners as mostly standalone components. The result was that on each shop floor worked many different components individually. An interoperability level was necessary for the Z-Fact0r system to be a solution to work as a whole. Various integration processes and extensive planning took place during the project and created an integrated system as a final product. The interoperability between the components was the first essential characteristic for the integration process. The components were desinged in the system, in a way that allowed them to operate together without conflicts during data streaming and operation.

Comment:

Z-Fact0r architecture was based on the modular design of the components and then the integration of the components to a complete system. For each component a specific architecture was followed by the responsible technology providing partner, base on the use cases, scenarios, end user requirements and technical requirements. The desing for each component was documented in the respective deliverable. Each component also followed the technological trends of their fields and exploited the state of the art of the field. An overall ontology of the Z-Fact0r system was created to include all possible actors, functions, assets etc. All components were initially deployed as standalone applications and then an integration plan was implemented. Z-Fact0r project followed the Incremental Integration Strategy (IIS) where the components were deployed on the shop floors and integrated as one.

Comment:

The Z-Fac0r project followed the AMQP and MQTT protocols for the communication between the components. A message brocker was develope by HOLONIX and was called iLike. The iLike implemented the publish/subscribe mechanism for all components which connected to it. The components were authorised in the iLike brocker and repository with a Bearer Token and then used the mechanism to publish or receive the data. An open API was used to create REST GET calls in order to initiate the communicatio between the component and the brocker. The communication steps between the component and the brocker were:

GET call by the component to initiate communication
The component is authenticated by the iLike machine
The iLike machine appoints the respective topics for the components to publish or subscribe to them
A component published data to a topic and another subcribes to the topic to receive the data

The data from the iLike machines are sent into the cloud to a broker using MQTT protocol (a lightweight protocol that transports messages between devices), it stores the data as messages, so the subscribers can get the values.
MQTT broker can easily scale from a single device to thousands, manage and tracks all client connection state and permit secure connections.

Comment:

Wireless communication of the Z-Fact0r solution was based on Wi - Fi protocol.

Comment:

The Incremental Integration Strategy (IIS) provides a unified framework for all the EU distributed partners, to work on common principles. By following the IIS, we try to ensure that the integration will be successfully executed in a timely manner. It defines a number of factors to monitor and steps to execute.

The IIS manifests that the components are integrated and tested incrementally and tested to ensure smooth interaction among them. Every component is combined incrementally, i.e., one by one till all components are integrated logically to make the required application, instead of integrating the whole system at once and then performing testing on the end product. Integrated components are tested as a group to ensure successful integration and data flow between components. The process is repeated until all components are combined and tested successfully. The tests included in the IIS are:

Load test
Stress test
Spike test
Endurance test
Scalability test
Volume test

Comment:

The IIS and the Integration plan of the Z-Fact0r solution were based on the same APIs and protocols as the data exchange in the system. There were no new APIs designed for the integration process and the integration protocol implemented was derived by the IIS and the Integration plan of the Z-Fact0r system.

Comment:

During the integration phase the same communication protocols were used: HTTP and AMQP for the data exchange. Also there is Wi - Fi connection for integration the various components and their updates on premises or on cloud during the integration process of the system. Finally, FTP was used during the integration phase for quick transfer of files on the shop floor premises.

Comment:

The data exchange format throughout the project's components was JSON. JSON lightweight, easy for humans to read and write it and provides all relevant information in a formatted way. It is also easy to change to include further fields when necessary or to be restructured for other components. XML was also used as data exchange format. XML also has the same characteristics with JSON in regards to easiness and accessibility. An example of one of the JSON formats used the project is given below to describe the prediction outputs:

Comment:

Semantic interoperability is desired in the project. An ontology was created to describe all the entities participating in the project components, system, communication protocols as well as the entities given by the end users. The Context Aware algorithm was based on this ontology to create the operation rules for the system. The algorithm provided the essential information to other components about the implementation of the solution. For example, the Context Aware algorithm provided the Reverse Supply Chain with all the necessary information about the production line, the production stages, the return levels and then the RSC was able to create a set of rules to implemented by the end user.

Comment:

The whole platform of the Z-Fact0r solution was able to work with other external applications, through a message brocker which is able to receive and send data to external systems. The interoperability level between the Z-Fact0r platform and external applications is essential for communication and integration purposes. Security and safety issues arise when different platforms cooperate. The Z-Fact0r platform implemented an AAA mechanism (Access, Autorisation and Authentication) to secure the safety of the platform during the connection with other external applications.

Comment:

Access was given to the Z-Fact0r platform to only authorised users. The platform installation was done either on the shop floor premises or servers deployed by the technical providing partners creating a limited access environment. There was also the authorisation between the components and external appl, where the each component was authorised in an authorisation server with their unique Bearer Token in order to subscribe in the message brocker and publish or receive the available data. Further steps, such as user authentication, were not included in the project scope.

Comment:

Z-Fact0r hybrid framework, obtained by applying a software and hardware integration strategy, is installed on the industrial end users shop floors. This architecture exploits features from Relational Databases and Triplestore while using the blackboard architectural pattern which ensures efficient and accurate communication of data transfer among software applications and devices.

Comment:

There is little integration with legacy systems, such as CMMS or ERP for the Z-Fact0r solution.

Comment:

The RESTful API over HTTP has been chosen to fulfil the necessity of sending intermediate or final results to the repository from Z-Modules side, the API utilizes JSON as default exchange format and JWT (JSON Web Token) as authentication mechanisms.
The JWT is a standard that defines a JSON format scheme for exchanging information between various services. JWTs are widely used to authenticate requests in Web Services authentication mechanisms where the client sends an authentication request to the server, the server generates a signed token and returns it to the client which, from that moment on, will use it to authenticate subsequent requests.

Comment:

To store data from different sources, including the data elaborated by various Z-Modules a Z-Fact0r data repository has been developed.
The first source of data is the temporal machine data coming from machine sensors, to store this data is used Cassandra, a distributed NoSQL DBMS capable to handle large amount of data across many servers and provide high availability.
The following one is used to store others complex and structured production information with the relational DBMS Mysql.
Another data source in the Z-Fact0r context is the output generated by various modules that carry out the analysis result.

Comment:

All database schema, communication protocols, security applications of the Z-Fact0r solution are designed to accommodate the scalability of the solution. All technology can be implemented in larger scale projects without major changes. The one difference with dealing with big data is the use of a different database approach, such as MongoDB, which is more suitable for big data analysis.

Z-Fact0r middleware platform and components Result description OPC UA) with any kind of sensors and actuators on the shop floor.
Semantic/information interoperability Taxon description For example through APIs, WSDL, RESTFUL, SOAP, OPC UA, WEBSOCKET, ISA 95, ISA 88, IEC 61499

vf-OS | Virtual Factory Open Operating System

01-10-2016

-

30-09-2019

: 115

Show more information

ICT performance characteristics

Comment: vf-OS will develop a concept for privacy and security handling, and will ensure that the concept is applicable to and followed by all vf-OS components. It will consider existing approaches (e.g. encryption), the specific requirements of the manufacturing domain, and the need for data security.

Results:

vfOS - ID4.4a - Security & Data Access(M18)

Comment: Dockerised components to adapt a vf-OS Platform instance to the requirements of a specific tenant

Comment: Middleware providing messaging and Pub/Sub Services to all components. Virtual Factory Devices Drivers and Open APIs, a set of modules that provide interfaces to physical assets (eg, Sensors) and virtual assets (eg, ERP systems and data) and ease their use in vf-OS

Comment: The vf-OS publish-subscribe middleware will provide the data infrastructure and will be fully compatible with major industry standards (i.e. JBI, SCA, BPEL or WSDL). IO Toolkit to implement connectors to devices or business software and specific implementations for OPC UA and MQTT. Other standards as ANSI/ISA-95 will be followed.

Comment: The IO Toolkit implements clients to the REST vf-OS kernel and middleware services facilitating the integration of virtually any technology

Results:

vfOS - ID5.3a - Data Harmonisation(M18)

Comment: Centralised token based security framework for REST APIs.

Comment: REST APIs for role based access management and security policy

Comments IO Toolkit to implement connectors to devices or business software and specific implementations for OPC UA and MQTT. Other standards as ANSI/ISA-95 will be followed.
Semantic/information interoperability Taxon description For example through APIs, WSDL, RESTFUL, SOAP, OPC UA, WEBSOCKET, ISA 95, ISA 88, IEC 61499
Standards Comments IO Toolkit to implement connectors to devices or business software and specific implementations for OPC UA and MQTT. Other standards as ANSI/ISA-95 will be followed.
Integration level interoperability Comments IO Toolkit to implement connectors to devices or business software and specific implementations for OPC UA and MQTT. Other standards as ANSI/ISA-95 will be followed.

SAFIRE | Cloud-based Situational Analysis for Factories providing Real-time Reconfiguration Services

01-10-2016

-

30-09-2019

: 34 | : 4

Show more information

ICT performance characteristics

Comment: Security, privacy & trust (SPT) based on situational awareness, based on: - Policy Enforcing Scheme - Distributed Reference Monitor (DRM) Functionalities: Encryption, Authorisation, Authentication, Monitoring, Auditing

Results:

SAFIRE Electrolux pilot: Cloud-driven product optimization

SAFIRE OAS pilot: Optimisation of production processes and preventive maintenance activities

SAFIRE ONA pilot: Adaptive Machining

Comment: Each SAFIRE service will be developed as own docker container, to allow easy distribution and scalability of whole SAFIRE solution in the cloud

Comment: Docker based application packaging and deployment will beused in SAFIRE

Comment: Publish / Subscribe message system Apache Kafka will be used for communication in SAFIRE

Comment: IISF based access control framework to allow integration of additional external components into SAFIRE. OPC-UA plug-in for the data ingestion. External systems can ingest data into SAFIRE solutio by either using pre-developed plug-ins (e.g. OPC-UA) or by developing own plug-in modules

Comment: Data Ingestion module will contain a plug-in architecture to allow integration of various data-source (e.g. OPC-UA)

Comment: Next Generation Access Control (NGAC) based authorisation and authentication

Comment: NGAC based access control management IN SAFIRE solution

Comment: Cloud based secure infrastructure for reconfiguration and optimisation. The envisaged SAFIRE infrastructure will be an add-on for an existing production system or next generation smart factory operating system, allowing to transform such production systems into advanced production systems capable of real-time reconfiguration and optimisation.

Results:

SAFIRE OAS pilot: Optimisation of production processes and preventive maintenance activities

Comment: Interconnected Systems of Production Systems (SoPS)

Results:

SAFIRE OAS pilot: Optimisation of production processes and preventive maintenance activities

SAFIRE ONA pilot: Adaptive Machining

Comment: Interconnected Systems of Production Systems (SoPS)

Results:

SAFIRE OAS pilot: Optimisation of production processes and preventive maintenance activities

SAFIRE ONA pilot: Adaptive Machining

Results:

SAFIRE Electrolux pilot: Cloud-driven product optimization

SAFIRE OAS pilot: Optimisation of production processes and preventive maintenance activities

SAFIRE ONA pilot: Adaptive Machining

Results:

SAFIRE Electrolux pilot: Cloud-driven product optimization

SAFIRE OAS pilot: Optimisation of production processes and preventive maintenance activities

SAFIRE ONA pilot: Adaptive Machining

Comment: Each SAFIRE service will be developed as own docker container, to allow easy distribution and scalability of whole SAFIRE solution in the cloud

Comments OPC-UA plug-in for the data ingestion. External systems can ingest data into SAFIRE solutio by either using pre-developed plug-ins (e.g.
Integration level interoperability Comments OPC-UA plug-in for the data ingestion. External systems can ingest data into SAFIRE solutio by either using pre-developed plug-ins (e.g.

ICP4Life | An Integrated Collaborative Platform for Managing the Product-Service Engineering Lifecycle

01-01-2015

-

01-01-2019

: 19 | : 6

Show more information

ICT performance characteristics

Comment: Several communication technologies depending on the service: Ethernet, OPC, OPC UA

Comment: Platform is devided in several components: front ends, backends, repositories.... Frontend is a portal composed of several portlets in liferay. Backend is a webservice communicated with the frontend on REST using JSON

Comment: The components of the platform are connected to the knowledge repository via API and with other sub-components via function calls

Comment: The services work mainly with machine data while the platform uses all type of file extensions (dwg, pdf,..) and text.

Comment: The platform is based on a semantic database where products, sensors, services, patterns and instances are linked. Their fuctionalities, characteristics and models are also linked one with each other.

Comment: ICP4Life will permit and demonstrate the design of products (machines, molds...) adapted to the manufacturing user requirements using the CUSTOMIZER and DESIGNER. This involves also the suppliers of machine components. For example: INERTIA is a sensor provider participating in the Project. The integration of sensors in complex products (machines) in a seamless way is the approach of the DESIGNER component of the platform. This way; ICP4LIFE permits an easy and friendly integration of field devices (sensors) in the production line equipment (machines) in order to acquire data and provide new services

Results:

ICP4Life Designer Component

I#Services: the ICP4Life Designer component focuses on the machine level, while integrating design process on sub-system level

Results:

ICP4Life Designer Component

#Service, #Connectivity: Designer component will act as a connector among different domain engineers, including PSS top managers, to facilitate their communication, data management, decision making, etc. Furthermore, it will perform a link to different specific legacy CAX tools to circulate the information flow and data sharing or management. Finally, since the different development stages of a PSS solution/offer will have inevitable interrelationships, there are interactions between the Designer component and the others on the ICP4Life platform.

Comment: ICP4LIFE platform permits the symbiosis of equipment supplier and user, providing the input from the user in the configuration of the product-service by the supplier. The interaction amongst both companies is a key aspect of the project. Services permit the optimization of the productivity (both the manufacturing system supplier as well , the user of the manufacturing system) resilieance, and maintenance services offered by the manufacturing system supplier (Enterprise).

Results:

ICP4Life Designer Component

#Service, #Connectivity: Designer component will act as a connector among different domain engineers, including PSS top managers, to facilitate their communication, data management, decision making, etc. Furthermore, it will perform a link to different specific legacy CAX tools to circulate the information flow and data sharing or management. Finally, since the different development stages of a PSS solution/offer will have inevitable interrelationships, there are interactions between the Designer component and the others on the ICP4Life platform.

Comment: Version from LUIS: ICP4LIfe concentrates on the design and optimization of product-service systems (machines, molds). These are the use cases to validate the platform. But the platform could be also used to design and engineer final products like household appliances (washing machines, fridges), toys or whatever other product.

Comments Interoperability (ICT) ICT performance characteristics Several communication technologies depending on the service: Ethernet, OPC, OPC UA Semantic/information interoperability ICT performance characteristics
Semantic/information interoperability Taxon description For example through APIs, WSDL, RESTFUL, SOAP, OPC UA, WEBSOCKET, ISA 95, ISA 88, IEC 61499

openMOS | Open dynamic Manufacturing Operating System for Smart Plug-and-Produce Automation Components

10-01-2015

-

30-09-2018

: 28 | : 4

Show more information

OPC UA for Plug&Produce: Automatic Device Discovery using LDS-ME Result title OPC UA for Plug&Produce: Automatic Device Discovery using LDS-ME

EMC2-FACTORY | Eco Manufactured transportation means from Clean and Competitive Factory

01-10-2011

-

30-09-2014

: 10 | : 3

Show more information

Energy Profile for Manufacturing Execution Systems Result description The flexible and scalable system energy profile based on the OPC UA interface is used.

A4BLUE | Adaptive Automation in Assembly For BLUE collar workers satisfaction in Evolvable context

01-10-2016

-

30-09-2019

: 15 | : 4

Show more information

ICT performance characteristics

Comment:

Security and privacy risk assessment to identify countermeasures to be included in the A4BLUE framework.

Comment:

Integration with automation mecahinsms through pulg and produce capabilities based on OPC UA.

Comment:

Integration with end-users MES systems.

Comments - For integration with automation mechanisms (Plug & Produce Adaptive Automation) OPC UA standard (EN 62541) is used.
Standards Comments - For integration with automation mechanisms (Plug & Produce Adaptive Automation) OPC UA standard (EN 62541) is used.

COMVANTAGE | Collaborative Manufacturing Network for Competitive Advantage

01-09-2011

-

31-08-2014

: 6 | : 6

Show more information

ICT performance characteristics

Comment: Collaboration space for manufacturing-oriented virtual enterprises (of distributed collaboration partners/stakeholders) - location independent access based on mobile applications, interlinking remote resources (e.g. experts, business data, field data,...)

Simplified interface for remote machine access Result description The interface is designed as a generic middleware adapter and was developed for 2 specific middleware solutions: GAMMA V and OPC UA.

ReCaM | Rapid Reconfiguration of Flexible Production Systems through Capability-based Adaptation, Auto-configuration and Integrated tools for Production Planning

11-01-2015

-

31-10-2018

: 29 | : 5

Show more information

ICT performance characteristics

Results:

Capability catalogue

Semantic/information interoperability Taxon description For example through APIs, WSDL, RESTFUL, SOAP, OPC UA, WEBSOCKET, ISA 95, ISA 88, IEC 61499

NIMBLE | Collaboration Network for Industry, Manufacturing, Business and Logistics in Europe

01-10-2016

-

30-09-2019

: 60 | : 6

Show more information

ICT performance characteristics

Comment: End-to-end security: Data integrity, confidentiality, identity and key management, authentication, fine-grained authorization and access control. Trust and reputation management. Advanced behavioural security (including game theory) Spring Cloud Security: Standardized security mechanisms are implemented using Spring Cloud Security. It provides out-of-the-box integration of security modules to Spring Cloud applications. Authentication and authorization between microservices are realized by using Spring Cloud Security, which supports OAuth2 and OpenID Connect and communicates with the authentication server (i.e. Cloud Foundry UAA).

Results:

Design and Implementation of Security and Privacy for Core Business Services

Comment: Refrain from proprietary formats; if necessary, build adapters that go both ways (import/export). Platform-independent micro-service architecture (micro-services are designed to be independent of Bluemix stack (but can use it if it’s there)) Standards compliance for product categorisation (eClass), business process specification (UBL), oneM2M for manufacturing interoperation.

Comment: (1) Docker-based (2) Bluemix/Kubernetes-based cloud solution

Comment: NIMBLE Task 2.3 OpenAPI for the NIMBLE Platform

Comment: Web objects for IoT data ingestion

Results:

Design of an Open API for the NIMBLE Platform

Comment: Open published API for 3rd party extensions. Intelligent support for business negotiation. Mainly driven by UBL documents connected to defined business processes; NIMBLE OpenAPI

Comment: B2B collaboration: Semantic annotation of products and services. Business process design and execution. Open ontologies. UBL for business processes, eClass for products, domain specific ontologies aligned via light-weight upper ontology

Comment: KeyCloak - based on Standards (OpenID Connect, OAuth 2.0 and SAML 2.0)

Comment: KeyCloak based Identity and Access Management of NIMBLE Platform

Comment: IIRA is the main reference. IIRA is closest in terms of conceptual design for NIMBLE. RAMI is not so applicable to us because we are closer to Internet B2C or B2B platforms. Industrial Data Space is on our radar, but was not sufficiently elaborated at the time of writing the proposal. See https://cloud.effra.eu/index.php/s/NiyTZgM3kw6VCxw The NIMBLE platform is designed to ingest data stemming from edge devices into the platform. Once data has reached the platform, data are stored for future uses such as offline analytics and auditing. In addition, processing of the data as it flows into the platform can be performed in real-time. Offline analytics complements the real-time view by enabling companies to gain insights from their data leading to more efficient processes. We follow the microservice approach for the NIMBLE architecture. Each microservice offers a specific and narrowly defined functionality that is deployed as an independent service [2]. It puts emphasis on real-time application monitoring, including architectural elements and business relevant metrics, e.g. number of orders per minute [2]. In addition, this approach provides decentralized data management and decentralized data storage decisions based on a polyglot persistence method. Microservices can still be combined with monolithic enterprise applications (monolith’s APIs) built as single units, fostering the federation and collaboration of various independent services in the Cloud. Figure 1 depicts the top-level architecture, which is inspired by the microservice infrastructure presented in [3]. Figure 2 then shows the core business services of the platform in more detail. The Gateway Proxy is the public entry point to the microservice application. All user requests are received via the Gateway Proxy and routed to the appropriate service. The Service Logging aggregates log outputs of each individual microservice and makes them available via a Web interface. The Service Monitoring collects data, which are necessary to monitor failures of services; this is implemented using the Circuit Breaker pattern [4]. The Service Monitoring can be used to monitor remote calls, or in any situation where parts of a system need to be protected from failures in other parts. After the number of erroneous executions exceeds a defined threshold, all future calls are immediately returned with an error without the actual function being executed. The Service Discovery enables registration of microservices, as well as mapping between service identifier and the endpoints of instances (e.g. URL or IP address). The role of the Service Configuration is to provide configuration settings for each service. The service communication is enabled either via REST (i.e. HTTP) or by using the Messaging Service (based on Apache Kafka), which provides asynchronous and scalable communication. Finally, the User Account and Authentication (UAA) & Identity Management administrates user identities on the platform. It combines the three standard protocols: OAuth2 for delegated authorization [5], OpenID Connect for session and authentication information [6], and the System for Cross-domain Identity Management (SCIM) for user and group management [7].

Results:

Design and Implementation of Security and Privacy for Core Business Services

Comment: Resilience is partly addressed through the federation aspects: attackers need to “hack” more than one platform, each with a different security setup, chosen from NIMBLE modules.

Semantic/information interoperability Taxon description For example through APIs, WSDL, RESTFUL, SOAP, OPC UA, WEBSOCKET, ISA 95, ISA 88, IEC 61499

QU4LITY | Digital Reality in Zero Defect Manufacturing

01-01-2019

-

31-07-2022

: 77 | : 15

Show more information

ICT performance characteristics

Results:

D2.11 Reference Architecture and Blueprints (Version 1)

Permissioned Blockchain for ZDM (Version 1)

Comment: Associated to QU4LITY Reference Architecture: Distributed Trustworthiness Layer

Details: Cyber Security in Industrial Environments

Comment: Associated to QU4LITY Reference Architecture: Distributed Trustworthiness Layer

Details: Cybersecurity (basis standard, inkl. terms and concepts relating to cyber security and cyber risk management)

Comment: Associated to QU4LITY Reference Architecture: Digital models and Vocabularies

Details: Information security management systems; Vocabulary

Comment: Associated to QU4LITY Reference Architecture: Collaboration, Business and Operation Service (CRM, ERP/MES, SCM, DSS)

Details: ISMS: Establishing, implementing, maintaining and continually improving an information security management system within the context of the organization (Information security)

Comment: Associated to QU4LITY Reference Architecture: Distributed Trustworthiness Layer

Details: Security RA

Comment: Associated to QU4LITY Reference Architecture: Edge/Fog

Details: Edge Computing

Comment: Associated to QU4LITY Reference Architecture: Distributed Trustworthiness Layer

Details: General concepts and principles of IT security evaluation; general model of evaluation

Comment: Associated to QU4LITY Reference Architecture: Distributed Trustworthiness Layer

Details: IT Security, requirements, evaluation criteria for IT security

Results:

Permissioned Blockchain for ZDM (Version 1)

Results:

D2.11 Reference Architecture and Blueprints (Version 1)

Library of Integrated, Interoperable Digital Enablers (Version 1)

Standards Compliance and Interoperability Specification (Final version)

Connectivity Technologies for Autonomous Quality (Version 1)

Comment: Associated to QU4LITY Reference Architecture: Network

Details: Connectivity requirements: Specifications (models) for low-data-rate wireless connectivity with fixed, portable, and moving devices with no battery or very limited battery consumption requirements

Comment: Associated to QU4LITY Reference Architecture: Factory Network/ Field and Proximity Network: Analog Inputs, Real-Time Ethernet, Digital IOs, Camera Link, P&P

Details: Feldbus/Device level (EtheCAT, PROFINET): Generic concept of fieldbuse

Comment: Associated to QU4LITY Reference Architecture: Corporate Network/ Production OT Access Network: Deterministic Ethernet (TSN), OPC-UA, IDS/NGSI-LD

Details: AMQP

Comment: Associated to QU4LITY Reference Architecture: IoT Automation Services

Details: Production system engineering; process quality and optimisation designer; distributed industrial-process measurement and control systems

Comment: Associated to QU4LITY Reference Architecture: Cross-cutting

Details: JSON

Comment: Associated to QU4LITY Reference Architecture: IoT Automation Services

Details: Production system engineering; process quality and optimisation designer; distributed industrial-process measurement and control systems

Results:

D2.11 Reference Architecture and Blueprints (Version 1)

Comment: Associated to QU4LITY Reference Architecture: Digital models and Vocabularies

Details: AAS, Interoperability

Comment: Associated to QU4LITY Reference Architecture: Digital Twin and Planning Services

Details: General principles of the Digital Factory framework

Comment: Associated to QU4LITY Reference Architecture: Digital models and Vocabularies

Details: Information security management systems; Vocabulary

Comment: Associated to QU4LITY Reference Architecture: Cross-cutting

Details: RA/RM (basic standard) applied for QU4LITY-RA

Comment: Associated to QU4LITY Reference Architecture: Cloud

Details: Use of open souce plattform for messaging and data streaming.

Comment: Associated to QU4LITY Reference Architecture: IoT Automation Services

Details: Production system engineering; process quality and optimisation designer; distributed industrial-process measurement and control systems

Comment: Associated to QU4LITY Reference Architecture: Distributed Trustworthiness Layer

Details: Cyber Security in Industrial Environments

Comment:

Associated to QU4LITY Reference Architecture: Corporate Network/ Production OT Access Network: Deterministic Ethernet (TSN), OPC-UA, IDS/NGSI-LD

Details: OPC UA: an industrial M2M communication protocol for Interoperability; Information modelling

Comment: Associated to QU4LITY Reference Architecture: Digital models and Vocabularies

Details: AAS, Interoperability

Comment: Associated to QU4LITY Reference Architecture: Digital Twin and Planning Services

Details: General principles of the Digital Factory framework

Comment: Associated to QU4LITY Reference Architecture: Digital Twin and Planning Services

Details: Blockchain

Comment: Associated to QU4LITY Reference Architecture: Control Service

Details: OS: Robot Operating System

Comment: Associated to QU4LITY Reference Architecture: Cloud

Details: Use of open souce plattform for messaging and data streaming.

Comment: Associated to QU4LITY Reference Architecture: Digital models and Vocabularies

Details: Vocabulary, Interoperability, used to define the schema and enable a publisher to describe datasets and data services in a catalog using a standard model and vocabulary that facilitates the consumption and aggregation of metadata from multiple catalogs.

Comment: Associated to QU4LITY Reference Architecture: Factory Network/ Field and Proximity Network: Analog Inputs, Real-Time Ethernet, Digital IOs, Camera Link, P&P

Details: Feldbus/Device level (EtheCAT, PROFINET): Generic concept of fieldbuse

Comment: Associated to QU4LITY Reference Architecture: IoT Automation Services

Details: Production system engineering; process quality and optimisation designer; distributed industrial-process measurement and control systems

Comment: Associated to QU4LITY Reference Architecture: Distributed Trustworthiness Layer

Details: Cyber Security in Industrial Environments

Comment:

Associated to QU4LITY Reference Architecture: Corporate Network/ Production OT Access Network: Deterministic Ethernet (TSN), OPC-UA, IDS/NGSI-LD

Details: OPC UA: an industrial M2M communication protocol for Interoperability; Information modelling

Comment: Associated to QU4LITY Reference Architecture: Digital models and Vocabularies

Details: AAS, Interoperability

Comment: Associated to QU4LITY Reference Architecture: Digital Twin and Planning Services

Details: General principles of the Digital Factory framework

Comment: Associated to QU4LITY Reference Architecture: Digital models and Vocabularies

Details: Data Models: proposes an overarching integrated conceptual model that describes interactions between the physical world, the user, and digital information, the context for AR-assisted learning and other parameters of the environment

Comment: Associated to QU4LITY Reference Architecture: Digital Twin and Planning Services

Details: Blockchain

Comment: Associated to QU4LITY Reference Architecture: Digital models and Vocabularies

Details: Qualit modelling and support of quality workflow scenarious

Comment: Associated to QU4LITY Reference Architecture: Digital models and Vocabularies

Details: Information model (QIF) and data formed into XML instance files support the entire scope of model based definition manufacturing quality workflow

Comment: Associated to QU4LITY Reference Architecture: Cloud

Details: Cloud computing, Fundamentalsn for Cloud services and devices: data flow, data categories and data use;

Comment: Associated to QU4LITY Reference Architecture: Cross-cutting

Details: JSON

Comment: Associated to QU4LITY Reference Architecture: Digital models and Vocabularies

Details: IoT, Semantic interoperability

Comment: Associated to QU4LITY Reference Architecture: Assets & Smart Products

Details: LCM: Enabling digital physical asset lifecycle management spanning plants, platforms and facilities; functional and interoperability requirements for Critical Infrastructure Management on a cross-sector basis

Comment: Associated to QU4LITY Reference Architecture: Digital models and Vocabularies

Details: Interoperable information model, vocabulary, and encoding mechanisms for representing statements about the usage of content and services.

Comment: Associated to QU4LITY Reference Architecture: Corporate Network/Plant IT Service Network: 5G, Wireless, Wired Etherne

Details: Interoperability & Common APIs: straightforward integration of a machine tool into higher level IT systems

Comment: Associated to QU4LITY Reference Architecture: …

Details: Applied to address performance analysisi and porcess optimisazion (i.e. allows to capture data that is required to do performance analysis of production facilities)

Comment: Associated to QU4LITY Reference Architecture: Control Service

Details: OS: Robot Operating System

Comment: Associated to QU4LITY Reference Architecture: Factory Network/ Field and Proximity Network: Analog Inputs, Real-Time Ethernet, Digital IOs, Camera Link, P&P

Details: MT Connect: used to access real-time data from shop floor manufacturing equipment such as machine tools

Comment: Associated to QU4LITY Reference Architecture: Cloud

Details: Use of open souce plattform for messaging and data streaming.

Comment: Associated to QU4LITY Reference Architecture: Factory Network/ Field and Proximity Network: Analog Inputs, Real-Time Ethernet, Digital IOs, Camera Link, P&P

Details: Specification that standardizes the connection between cameras and frame grabbers and defines a complete interface (provisions for data transfer, camera timing, serial communications, and real time signaling to the camera)

Comment: Associated to QU4LITY Reference Architecture: Factory Network/ Field and Proximity Network: Analog Inputs, Real-Time Ethernet, Digital IOs, Camera Link, P&P

Details: API, Interoperability: global camera interface standard using the Gigabit Ethernet communication protocol to allow fast image transfer using low cost standard cables over very long lengths.

Comment: Associated to QU4LITY Reference Architecture: Corporate Network/ Production OT Access Network: Deterministic Ethernet (TSN), OPC-UA, IDS/NGSI-LD

Details: REST API: application of standards and specification for HTTP/REST APIs

Comment: Associated to QU4LITY Reference Architecture: Factory Network/ Field and Proximity Network: Analog Inputs, Real-Time Ethernet, Digital IOs, Camera Link, P&P

Details: Feldbus/Device level (EtheCAT, PROFINET): Generic concept of fieldbuse

Comment: Associated to QU4LITY Reference Architecture: IoT Automation Services

Details: Production system engineering; process quality and optimisation designer; distributed industrial-process measurement and control systems

Comment: Associated to QU4LITY Reference Architecture: Distributed Trustworthiness Layer

Details: Cyber Security in Industrial Environments

Comment:

Associated to QU4LITY Reference Architecture: Corporate Network/ Production OT Access Network: Deterministic Ethernet (TSN), OPC-UA, IDS/NGSI-LD

Details: OPC UA: an industrial M2M communication protocol for Interoperability; Information modelling

Comment: Associated to QU4LITY Reference Architecture: Digital models and Vocabularies

Details: AAS, Interoperability

Comment: Associated to QU4LITY Reference Architecture: Digital Twin and Planning Services

Details: General principles of the Digital Factory framework

Comment: Associated to QU4LITY Reference Architecture: Network

Details: Network: Wireless local area networks

Comment: Associated to QU4LITY Reference Architecture: Network

Details: Connectivity requirements: Specifications (models) for low-data-rate wireless connectivity with fixed, portable, and moving devices with no battery or very limited battery consumption requirements

Comment: Associated to QU4LITY Reference Architecture: Network

Details: Communication: Protocols, procedures, and managed objects for the transport of timing over local area networks

Comment: Associated to QU4LITY Reference Architecture: Digital Twin and Planning Services

Details: Blockchain

Comment: Associated to QU4LITY Reference Architecture: Corporate Network/ Production OT Access Network: Deterministic Ethernet (TSN), OPC-UA, IDS/NGSI-LD

Details: AMQP

Comment: Associated to QU4LITY Reference Architecture: Corporate Network/ Production OT Access Network: Deterministic Ethernet (TSN), OPC-UA, IDS/NGSI-LD

Details: MQTT: an extremel lightweight publish/subscribe messaging transport protocol

Comment: Associated to QU4LITY Reference Architecture: IoT Hubs

Details: IoT, information exchange, peer-to-peer connectivity and seamless communication both between different IoT systems