4 minute read

5 eManufacturing Experiment

Next Article
9 Sustainability

9 Sustainability

view the business prospects for cooperation between themselves and partners in the energy domain. It also creates the possibility to exchange best practices between Living Labs and creates an understanding of the measurable data in the experiments. We have studied the best ways to collect data, to show the measurement data to end users and to implement a user behaviour methodology to be used in the different Living Labs.

The eManufacturing experiment focused on technical implementation of several Future Manufacturing use cases based on using a SAP Research middleware platform prototype. Due to the economic crisis onboarding of Hungarian SMEs by the local Living Lab proved not feasible; instead in a dual cross-border setting of Portugal and Germany, a very close collaboration was set up and organized. For SMEs, Living Labs as well as the Large Enterprise involved there was a clear value added of participating in the project, which was fundamental for the cross-border project collaboration.

Advertisement

The experiments entailed the usage of a middleware platform prototype for plant energy monitoring and management (Germany), tracking and tracing of tools and material in a factory environment (Germany), energy consumption monitoring (Portugal), and asset viewing and management (Portugal).

Various means for collaboration, proper project management and technology training and transfer were applied and validated, both from the pilot team’s own selection and based on recommendations from WP1. A new means for building trust has been identified, when faceto-face meetings are not possible: the webcam tour combined with online application sharing lays a foundation for building trust in the technology capabilities of the partner, which is essential in the manufacturing environment. And the possibility to being exposed through such a means after having successfully completed a project with the Future Factory in Germany offers a valuable means of communication in addition for any SME abroad.

With respect to IPR issues, especially with the supporting partners, who were not bound by the APOLLON consortium agreement, contracts like “Software Development Licensing

Agreement” and “Test and evaluation agreement” were generated, which could be of relevance for similar project activities, where e.g. one company wants to work on prototypes prior to product release.

A surprise was that the technical cross-border project went through very well. The conclusion was, that in IT and B2B environment the language is mostly English, the terminology somehow universal, the processes from idea or concept to product via testing as well, so time could be taken to address the human factors and not make them become a hurdle.

Technology transfer was executed across borders. Creation of new products and service offerings, which was meant to be done as co-activity between partners in Hungary and Portugal for both customers in Portugal and Hungary, could not be done, thus happened locally.

The ongoing collaboration on the pilot and especially the difficulties faced in Hungary raised the awareness for means to better support finding the right partners abroad to start a new business and to find new customers. Whereas in the Portuguese case the local Living Lab proved to be the “trusted hub” for partner and customer identification, the question was how to support partner selection, business initiation and collaboration outside the current ecosystem.

This resulted in the new concept of “APOLLON Marketplace” platform initiated by SAP Research. The Apollon Collaboration Platform is based on the Open Source Prototype “USDL Marketplace” developed within the Theseus Texo project. It consumes and exposes services described in the Unified Service Description language (USDL), a platform-neutral language for describing business details of a service, such as pricing, service-levels, and legal aspects in a standardized way. This and the central concept of abstract services, which is used to cluster services that comply with a number of predefined description properties, lead to enhancements in comparability and exchangeability of services. The main purpose of such a marketplace is to support service providers and service consumers in the matchmaking phase.

For the APOLLON project, a customized USDL Marketplace was set up as an Internet-based platform to the domain networks of Living Labs. Service providers (in particular SMEs) often act within tight budget boundaries, especially for investments in market research, for business development or for promotion/marketing. Thus the APOLLON Collaboration Platform offers mechanisms that support trading services across borders in new target markets. In particular when a service provider need to find early adopters and future customers for new products in a market it is not familiar with. The APOLLON Collaboration Platform offers help to moderate the processes of finding the right partners, users and future customers to incubate business collaboration. The components which were used for the Apollon Platform are depicted in the diagram below. Notice that the terms “Service” and “Solution” are used interchangeable here.

As illustrated in the architecture diagram, the Matchmaking component is about discovering and matching offering and demand. It provides functionality to browse the catalogue and search for services as well as shopping cart functionality for services with a fixed price or for services that require an RFQ process in advance. The shopping cart is directly connected to the RFQ&Ordering component which handles everything related to RFQ processing, bargaining, ordering, and delivery management. For authentication and authorization of users, the corresponding component is used. It redirects platform users after their login directly to an individual view on the collaboration platform associated with their role on the system (service consumer, service provider and administrator). While the service consumer’s individual view focuses on matchmaking functions and RFQ/Order processing, the provider’s

This article is from: