Projects overview

Sort by

Toggle all information

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

01-01-2015

-

31-12-2018

Show more information
ICT performance characteristics
Interoperability (ICT)
Comment: Several communication technologies depending on the service: Ethernet, OPC, OPC UA
Industrial Reference ICT Architectures
Reference Architectural Model Industrie 4.0 (RAMI 4.0)
RAMI 4.0 Hierarchy Axis
Product
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.

BEinCPPS | Business Experiments in Cyber Physical Production Systems

11-01-2015

-

31-10-2018

Show more information
ICT performance characteristics
Interoperability (ICT)
Result items:
Lombardy Champion - Zero-Hours Quality
Lombardy Champion - Zero-Hours Quality
Rhône-Alpes Champion: The Smart Mold
Rhône-Alpes Champion: The Smart Mold
OPC-UA for M2M communication, and NGSI for data publishing on the cloud
Industrial Reference ICT Architectures
Reference Architectural Model Industrie 4.0 (RAMI 4.0)
RAMI 4.0 Hierarchy Axis
Product
Result items:
Lombardy Champion - Zero-Hours Quality
Lombardy Champion - Zero-Hours Quality
The system is applied to whole Product items as they leave the assembly line.
Rhône-Alpes Champion: The Smart Mold
Rhône-Alpes Champion: The Smart Mold
The plastic pieces as a result of the injection process.

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

01-10-2016

-

31-03-2020

Show more information
ICT performance characteristics
Interoperability (ICT)
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.
Industrial Reference ICT Architectures
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].
Reference Architectural Model Industrie 4.0 (RAMI 4.0)
RAMI 4.0 Hierarchy Axis
Product

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

01-10-2016

-

31-10-2019

Show more information
ICT performance characteristics
Interoperability (ICT)
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.
Result items:
CPS Data Model Architecture - M24 release
CPS Data Model Architecture - M24 release
Industrial Reference ICT Architectures
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).
Reference Architectural Model Industrie 4.0 (RAMI 4.0)
RAMI 4.0 Hierarchy Axis
Product
Powered by Chris Decubber BV