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

Full project page

Data communication and interoperability

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.


Integration with legacy systems

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

Platform level interoperability
View Kanban

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.

  • AAA - Access, Authorisation and Authentication

    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.

  • User Acccess and Rights Management
  • Motivating Scenario / Use-Case

Application level interoperability
View Kanban

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.

  • Web-services / Composability
  • Modular Design and Deployment Approaches

    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-Fa ...

  • Open APIs and Communication Protocols

    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:

    1. GET call by the component to initiate communication
    2. The component is authenticated by the iLike machine
    3. Th ...

Integration level interoperability
View Kanban

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 succe ...

  • Semantic/information interoperability

    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.

  • Data/object model interoperability - Data exchange formats - APIs

    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:

    {"holRepoId":3621,"eventDate":1545061853990,"eventDateString":"1545061853990","asset":"Tresky machine","predictedGlueVolume":0.267 ...
  • Connectivity & network interoperability – communication protocols

    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.

  • APIs and Integration Protocols

    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.