DELIVERABLE Project Acronym:
APOLLON
Grant Agreement number:
250516
Project Title:
Advanced Pilots of Living Labs Operating in Networks
D 4.4 Pilot results and evaluation of the cross-border experiment
Revision: Final
Authors: JoĂŁo Lopes (Fiapal) Carsten Puschke (SAP)
Project co-funded by the European Commission within the ICT Policy Support Programme Dissemination Level P
Public
C
Confidential, only for members of the consortium and the Commission Services
X
Apollon – Deliverable D.4.4
The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. Statement of originality: This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both. Deliverable 4.4 Public
2
Final Version
Apollon – Deliverable D.4.4 Table of Contents 1.
Introduction ..................................................................................................................4
2.
Results Obtained ..........................................................................................................4
3.
APOLLON eManufacturing cross-border Collaborations...............................5
4.
Evaluation of experiments and Lessons Learned.......................................... 19
3.1 Set-up of Collaborations ..................................................................................................... 5 3.1.1 Living Lab Interoperability..................................................................................................... 6 3.1.2 Technical Interoperability ...................................................................................................... 7 3.1.3 Research Interoperability ....................................................................................................... 9 3.2 Manufacturing Use Cases ................................................................................................... 9 3.2.2 Future Factory Use Cases ........................................................................................................ 9 3.2.3 Fiapal Living Lab Use Cases..................................................................................................10 3.3 Cross-border activities .....................................................................................................12 3.3.1 Business Partnerships ............................................................................................................13 3.3.2 Application of Technology in local system landscapes .............................................13 3.3.3 Adoption of Knowledge .........................................................................................................15 3.4 Methodologies and tools used .......................................................................................16 3.4.1 Living Lab Methodology Process .......................................................................................17 3.4.2 Webcam Tour method description ...................................................................................18
5.
4.1 4.2
Assessment of SMEs activities and scalability..........................................................19 Assessment of Living Labs network scalability .......................................................20
Summary...................................................................................................................... 22
Deliverable 4.4 Public
3
Final Version
Apollon – Deliverable D.4.4
1. Introduction The deliverable reports on the evaluation of the manufacturing pilot and outlines the structured approach to the pilot evaluation Thus it illustrates the technical evaluation, research results, and findings of Living Lab interoperability and crossborder collaboration with respect to the implemented use cases in the German and Portuguese Living Labs. The use cases described in deliverable D4.2 and D.4.3 were implemented at the Living Lab in Dresden and Portuguese partner SMEs of WP4.
During the implementation, bugs and errors of the Middleware for Device Integration (MDI) platform were identified and reported back to the developers at Future Factory Living Lab of SAP Research Center Dresden, Germany. The MDI platform related issues were addressed by the SAP Research Center Dresden. Overall it can be concluded that the technical realization of the uses cases was a smart and easy project work because of the fact that all stakeholders had clear roles and responsibilities. The portuguese SMEs CENI and Imeguisa played the role as service receivers and articulated their demand for the realization of two use cases such as energy monitoring and asset viewing. Based on these requirements the other parties such as the Living Labs of Fiapal, the Future Factory of SAP Research in Dresden and the IT SME Ydreams sat together with the potential receiving parties and defined the project plan for the implementation of these use cases. The major KPI measured was "just" the success of the implementation of such a use case after a given timeframe. Of course that included "sub-KPI's" like the success of the used methods and tools described below.
For the avoidance of doubt we would like to state here that our Hungarian project partner HVEC will deliver a separate section to the next deliverable D.4.5 explaining the circumstances that lead to the drop off from the active use case execution. With the agreed amendment to the DoW we put clear adjustment of the project plan in place which will provide additional feedback how a global economic crisis impacted our work.
2. Results Obtained Concerning the cross-border activities that were established between SAP and Ydreams, in connection with the use cases implemented on premises of the involved Portuguese SMEs Imeguisa and CENI, full interoperability and technical implementation were achieved, following all defined specifications of the use cases. The successful implementation of the use cases was accompanied by a strong cross-border partnership established between SAP and Ydreams, based on close communication between technicians from both parties that successfully tackled integration obstacles and day-to-day problems, leading to a seamless solution that fulfilled the requirements at both Imeguisa and CENI. According to the initial set goals as listed in the DOW:
Deliverable 4.4 Public
4
Final Version
Apollon – Deliverable D.4.4 • • •
Advance the state of the art by adapting the MDI platform to support crossborder services and activities Improve collaboration amongst local SMEs (those that are connected to an individual Living Lab) and help them build services that are useful to relevant manufacturing use cases of interest to all Living Labs Initiate and improve collaboration amongst selected trans-national SMEs such that they can produce as well as consume each others' services using the platform as a basis. Moreover, potential inter-SME activities will be stimulated that are of benefit to all stakeholders (SMEs, Living Labs, and the local economy)
It can be repeatedly said that for the implementation phase of the use cases (the project work as such) everything went as expected.
If we look at the third bullet point saying that we also should focus on the initiation and improvement of the collaboration between the SMEs - this was identified as the area for with the highest potential. Once the business partners know each other and exchanged information of what should be delivered respectively received to/from the other party it's an easy "project game" to play. But making potential business partners aware of each other who are geographically far away is the biggest drawback.
We therefore decided to put our attention on this challenge for the last period of Apollon trying to introduce another platform which should act as a marketplace not just being a service trading platform but also offering collaboration aspects that allows an easier decision making to enter in cross border businesses. In connection to that we also look(ed) into the aspect how can Living Labs support those trans national businesses. The findings will be outlined below in the document.
3. APOLLON eManufacturing cross-border Collaborations 3.1 Set-up of Collaborations Based on the given use cases (energy monitoring & asset viewing) that we introduced with deliverable D.4.2 and D.4.3 we were seeking for the right setup how to monitor the progress of work and to be able to immediately react on exceptional situations like system shut downs, software bugs, knowledge gaps that require an immediate answer etc. In order to ensure such a systematic, regular and ad hoc collaboration between the Living Labs and the connected SMEs we established several methods and used various tools. The methods that are still in use or were used are listed below [1]: o M1: regular phone conferences on a weekly basis
Deliverable 4.4 Public
5
Final Version
Apollon – Deliverable D.4.4 o M2: technical support via email and phone
o M3: documentation exchange on the SAP Research Middleware for Device Integration prototype (MDI) including installation, usage, configuration etc.
o M4: use of internal APOLLON portal (myBBT) to share documents and to upload minutes
o M5: remote LL tour with the help of webcam and SAPconnect (incl. web sharing & conference calls) o M6: set-up service level agreements to ensure reliable technical support
o M7: software development & licensing agreement as a base for a trusted environment, where no consortium agreement was in place
The tools that are in use ore were used are listed below [1]: o T1: LinkedIn closed group
o T2: SAPconnect collaboration tool (web conferencing) for application sharing etc. o T3: myBBT platform for document sharing, minutes etc. o Tool 4: Skype conferencing
o Tool 5: SAPmats (download container tool for "large file" sharing) o Tool 6: webcam & audio
Actually for the internal WP4 collaboration the most important methods and tools are the regular conference calls to synchronize between each other on a weekly basis and the myBBT portal to store and archive documents, minutes and notes.
For external communication - not just to other Apollon WPs but also to any other interested parties we established webcam tours (M5) to systematically disseminate our achievements.
LinkedIn (T1) did not fulfil our requirements as a collaboration platform. B2B specific needs are absent or insufficiently developed for the requirements necessary for our collaboration infrastructure. 3.1.1 Living Lab Interoperability The interoperability between the Living Labs has been realized in a very open and direct way. Since the LL know each other they can help to bring SMEs to new markets as they play the a "hub role" taking off business to other countries. Because of the clear objectives to setup certain manufacturing use cases the Living Labs were in a very good interaction mode. The project processes and
Deliverable 4.4 Public
6
Final Version
Apollon – Deliverable D.4.4 requirements were not needed to be translated into country specific schemes but are everywhere the same. That helped a lot to start with the implementation right away.
Although the hungarian project partners had to jump off the project because of the financial crisis situation at the beginning of Apollon this was also the case there. The business and technical requirements analysis as well as project blueprint was easily done that day.
As described above the coordination happens on a regular basis using the project’s MyBBT portal, weekly telephone and Skype conference calls and email communication.
Together with our Work Package 1 liaison person, we are exploring, testing and finally developing tools and methodologies that will drive the next level of crossborder Living Lab collaboration for the manufacturing industries.
Within the SAP Research Future Factory Living Lab the collaboration is realized by many projects, use cases, demonstrators and prototypes that were built or are in progress. The various projects are running independently but using one and the same infrastructure which is under the responsibility of an SAP Research Future Factory core team. This team assures a consistent management - either being project specific or in the overall Future Factory context.
Within the Fiapal Living Lab the project activities have been carried out by Ydreams in direct liaison with the SMEs and under a direct coordination of Fiapal. A weekly teleconference assured an accurate follow up of the activities, complemented by site meetings for progress evaluation and validation. 3.1.2 Technical Interoperability As a result of the agreed use cases of WP4, SAP Research provided the Middleware for Device Integration prototype (MDI) as the technical basis. As described in deliverable D.4.3 the platform was introduced to all the stakeholders of WP4 in a face to face workshop held at SAP Research in Dresden. Finally it was shipped to the other Living Labs and respectively to the connected SME partners. This shipment included the executable software and a development kit as well as documentation to help the end users and developers. SAP Research Dresden explicitly named a colleague who took care of our partners in Portugal to setup and maintain the MDI platform prototype. A detailed description about MDI was already given with deliverables D.4.1 and D.4.2. In order to set a common understanding about the realization of the technical interoperability all parties that are involved agreed to certain service level agreements (SLAs) that include key performance indicators (KPIs) like: • • •
support personnel availability (during business hours) support message priority (high, medium, low)
message response time (within 60 minutes after message sending)
Deliverable 4.4 Public
7
Final Version
Apollon – Deliverable D.4.4 •
fix rate (how often goes information forth and back until the problem is solved)
With these figures the technical interoperability was set on a framework that perfectly facilitated our needs.
Coordinated by FIAPAL and in collaboration with the technical managers of Imeguisa and CENI the partner Ydreams analyzed the technical scenarios and conceptualized a technical solution for each use case in articulation with SAP technical liaison. In terms of architecture, the analysis of storage and communication components determined the choice of MySQL has the database, SOAP (Simple Object Access Protocol) Web Services and JSON (JavaScript Object Notation) Web services as interface protocols. SOAP web services were used in the communication between the ISA proxy and the MDI Platform and the JSON web services used in the communication between the YDreams Adapter and the User Interface. In the case of CENI, the scenario conceptualized by the participants, led to the choice of a third protocol, Serial communication over Bluetooth. This architecture proved to be effective accommodating the services supplied by the smart-meters and to communicate with the MDI web service agents, offering flexibility to accommodate other protocols as was the case of CENI. The adapters developed by YDreams for Imeguisa and CENI were implemented on top of SAP MDI using a so called Groovy agent.
With the contribution of FIAPAL expertise and through direct interaction with endusers Imeguisa and CENI, YDreams developed a web based GUI that proved through continuous utilization, to be effective and functional. A very fruitful collaboration between the technical developers of the SMEs and Living Labs allowed a really fast implementation of these two use cases.
During the setup and development of the solution some minor bugs were detected in the MDI platform which were reported to the developers at the Future Factory Lab of SAP Research. The colleagues in Dresden responded in line with the service level agreements. These issues were always promptly addressed and finally corrected in the provided posterior platform version. Further testing concluded the correction of these problems and the applications were at the end robust and in a fully functional mode continuously supporting the targeted objectives. The MDI is now at a final stage of development with benefits for SAP by all the inputs received and in a full use mode by the SMEs. This collaboration generated the exchange of experiences between the partners and lead to a systematic deployment and integration of the MDI platform prototype into the existing systems at Imeguisa and CENI according to the planned expectations. The SMEs now have available management systems designed according their specific needs and for their own benefit. Ydreams created specific knowledge for MDI use case developments and contributed for the introduction of new communication options like e.g. Bluetooth, enriching the spectrum of possible application scenarios. Deliverable 4.4 Public
8
Final Version
Apollon – Deliverable D.4.4
3.1.3 Research Interoperability As described in chapter 3.1.3 we were looking into aspects how to improve the knowledge exchange between the WP partners. As a core finding from the use case set-up we jointly identified requirements for a collaboration platform that specifically supports cross border businesses for SMEs in the area of the manufacturing industries.
This process began with a face-to-face meeting of all Work Package partners in Ydreams facilities in Portugal, were a web conference (SAPconnect) with other SAP specialists was held. After that the platform was conceptually defined through a co-design effort of all partners, during several conference calls and with the cocreation of the tools that the platform needs to fulfil for cross-border collaboration of SMEs.
This research work and the interaction between the different stakeholders was the starting point for the conceptual design of the collaboration platform mentioned above. For further details please refer to chapter 3.3.
3.2 Manufacturing Use Cases The following chapters will recap the use cases that we implemented by focusing on changes that occurred in the meantime since our last deliverable (D.4.3) report.
In relation to the previous period some minor adjustments were made to the visualization pages in the web clients, following suggestions by FIAPAL and Imeguisa. These requirements had some implications in terms of the web services provided by the smart meter provider which were addressed and implemented. Also during the final implementation stage a new version of the SAP platform was introduced that led to minor adjustments. This version addressed and corrected all the bugs and errors reported and it allowed to improve the robustness and performance of the application. 3.2.2
Future Factory Use Cases
With the use case built at SAP Research in Dresden we monitor and manage the energy consumption of production equipment at the SAP Research Future Factory. The technologies used are smart meter to measure energy consumption. In difference to the beginning of the setup of this use case we are now focusing on industrial smart meters only and therefore removed Bluetooth based smart meter technology which is more relevant for private house hold environments. The smart meter connectivity was one of the first projects where SAP Research introduced its MDI platform prototype. In order to position the heterogeneous approach of the use case not just in the backend but also at the client (UI) side the energy consumption data were made visible with an "Energy Dashboard� that uses Microsoft Silverlight technology. Deliverable 4.4 Public
9
Final Version
Apollon – Deliverable D.4.4
Figure 1: Industrial Smart Meter collecting energy consumption data of a milling machine at SAP Research Future Factory; © SAP AG, 2011
Figure 2: SAP Research Energy Dashboard Prototype based on Microsoft Silverlight; © SAP AG, 2011 3.2.3 Fiapal Living Lab Use Cases Imeguisa At Imeguisa, energy consumption monitoring was realized with three smart meters provided by the Portuguese SME ISA.
One smart meter is connected to the main electricity board which is the central power supply hub for all machines.
Two other smart meters are exclusively connected to two key machines - a CNC milling machine and a Pipe forming machine. An ISA proxy is collecting the data from the smart meters. The data is then cached and being made available to the MDI platform prototype web service agents. The agents process and save the Deliverable 4.4 Public
10
Final Version
Apollon – Deliverable D.4.4 information in the database. In terms of user interface design a very direct information presentation strategy was conceived, following FIAPAL advising and according to end-users requirements. The selected variables for each smart meter are presented graphically with three choices of time settings, corresponding to the end-user needs.
The YDreams adapter for Imeguisa was implemented on top of the SAP MDI platform prototype by using two main functions: • •
Read the data information from the web services and save it to the database Read the data information from the database and provide it to the user interface - Figure 3.
Figure 3: Energy monitoring UI
CENI
The objective at CENI was to monitor several workstations with specific characteristics and in a versatile environment. To achieve this objective, each workstation was equipped with an electronic interface module that is able to read the device default protocol and which then forwards the data via Bluetooth to the central server. This solution intention was to support workstation´s mobility in a factory environment. The YDreams adapter for CENI was implemented on top of SAP Research MDI platform prototype using three main functions: • •
Read the data information from the web services and save it to the database Calculating the post processing data periodically
Deliverable 4.4 Public
11
Final Version
Apollon – Deliverable D.4.4 •
Read the data information from the database and provide it to the user interface - Figure 4.
Figure 4: Asset viewing UI
3.3 Cross-border activities In the beginning the cross border activities were mainly focusing on the setup and realization of the use cases Energy Monitoring and Asset Viewing. The cross border activities always followed the same pattern meaning that each use case had its own life cycle where different cross border activities were relevant for a certain phase of the use case realization. The cross border activities and their order that we executed for can be listed as follows: • • • • • •
technical and business blueprint technology knowledge transfer use case implementation use case execution
support and maintenance
joint requirements gathering on a cross-border collaboration platform
A detailed description of these cross border activities will be given in the chapters 3.3.1 and 3.3.2. Deliverable 4.4 Public
12
Final Version
Apollon – Deliverable D.4.4 As already mentioned under 3.1.4 and based on the experiences that we gained during the realization of the use cases it became relatively early clear that it is very helpful to put a collaboration environment in place which facilitates the execution of these cross border activities.
Therefore during our second face to face workshop in Portugal (July 2011) we put a precise work plan together for the second half of our experimentation with the goal to finally provide a WP4 marketplace for SMEs which either provide or seek services. These services may include technology (hardware as well as software), consulting services or "open" services in the way of any kind of collaboration (best practices exchange) via the collaboration platform. For further details please refer to chapter 4. 3.3.1 Business Partnerships Although the business partnerships were given from the beginning of Apollon because of the fact that the nomination and contractual binding of all core partners under the Consortia Agreement (CA) as well as the selection of the supporting partners was done before we started to work on the use cases - we gained many experiences and insights how business relationships and finally partnerships between SMEs coming from different countries are actually built and how they can be improved.
Transparency, trust and an easy access to any type of information regardless if the SME is a service provider or a potential service consumer – is crucial to start running new business engagements. Initial cross border activities are always the selection of the right business partner with a discussion about the requirements and the collection of information if the SME (being the provider) can either solve my problem or if the SME (being the consumer) is looking for solutions that I can deliver. That can be named as the creation of a technical as well as business blueprint which we believe could be heavily enforced with a collaboration platform where different parties get easily in touch with each other.
For example with the Energy Monitoring use case as well as with the Asset Viewing use case there was already a business partnership created between a Living Lab (Future Factory) in Germany and an SME (Ydreams) in Portugal where the SME took advantage from the provisioning of a software technology - the SAP Research MDI platform prototype. The Portuguese SME combined that with his knowledge and expertise to solutions that helped other SMEs such as Imeguisa with their demand for energy monitoring and CENI with their demand for an asset viewing solution to get the right and best product and created two new business partnerships. 3.3.2 Application of Technology in local system landscapes Of course not just for the business side of a project but also for the technical aspects like the technology knowledge transfer, the use case implementation, the Deliverable 4.4 Public
13
Final Version
Apollon – Deliverable D.4.4 use case execution and support and maintenance - a clear structure of the cross border activities is a "must have". From the beginning, the WP stakeholders in Portugal and Germany were committed to regular calls and meetings to build the technical infrastructure needed for the respective use cases and to share best practices as they appeared. Besides the regular meeting series all partners were always in an "on-demand"availability in order to immediately react to unexpected technical issues.
To establish the specific requirements of each use case implementation, a close and dynamic collaboration was created e.g. on-site analyses cycles with the involvement of smart meter provider ISA was a step by step process that we iteratively fine-tuned during implementation.
Co-Design •business case analysis •collection of requirements •conceptual design •technical blueprint (MDI platform as well as UI relevant aspects)
Co-Implementation •technological knowledge transfer • Service Level Agreements (SLAs) during implementation •Ydreams development, equipment interfaces and implementation in coordination with Fiapal, SAP and SMEs
Co-Execution •Agent tests, evaluation of results and feedback to SAP LL •introduction of required corrections •constant support /maintenance •SLAs between technology provider and "customer" (software updates / upgrades)
Figure 5: Schematic view on Co-activities for WP4 use case
Deliverable 4.4 Public
14
Final Version
Apollon – Deliverable D.4.4 3.3.3 Adoption of Knowledge Through the establishment of cross-border business partnerships (B2B), using the APOLLON eManufacturing Living Lab approach, the collaboration accelerated the process of innovation and dissemination of new products / services and the exchange of knowledge. That is specifically proven by the fact that the second use case went live faster due to experiences already built up at YDreams (learning curve).
Different participating entities brought different contributions and had different objectives as it can be seen schematically in Figure 6.
Figure 6: Collaboration approach showing the participating entities and interests
This collaborative approach sped up the establishment of B2B partnerships, thus contributing to the dissemination of new SME solutions and within a broader market. Also, the co-creation of solutions and the collaboration allowed the widespread adoption of best practices. Figure 7 below schematically represents the collaboration tool priorities as defined in eManufacturing vertical domain.
Deliverable 4.4 Public
15
Final Version
Apollon – Deliverable D.4.4
Figure 7: Collaborative tool priorities, identified for an enhanced collaboration tool
3.4 Methodologies and tools used The Living Lab methodology, in a simplified definition, consists of the evaluation of products in real-life environments. Living Labs represent a user-centric innovation methodology for sensing, prototyping, validating and refining complex solutions in multiple and evolving real life contexts. By using the Living Lab methodology, researchers and innovative SMEs can gain a deeper understanding about how people interact with products and use services, finding constraints, new features or necessities; this leads to the development of better products that are more suited to user needs and expectations, thus increasing their success in user acceptance. Living Labs are a methodological approach, which can be positioned as a platform for user-driven innovation, building on and adding distinctive features to the tradition of action research (see Table 1). The user is recognized as a source of innovation and not just as a user or consumer in a narrow sense. Research is considered as the act of innovation and implementation of new B2B solutions. Lab research Controlled environment Limited, clearly assigned role of users Designed for
Action Research Real world setting, yet typically confined to an organisation or department Not specific about user role Active (social and
Deliverable 4.4 Public
Living Lab Real world setting, involving multiple stakeholders from multiple organisations and their interaction Active role of users as co-innovators; exposing technology to the creative & destructive energies of the users; facilitating dynamics of collective action Multi-disciplinary research teams actively 16
Final Version
Apollon – Deliverable D.4.4 replicability Designed for observation of outcome
political) role of researcher in the research setting
The researchers observe and take part in the creation of an outcome
involved in the research settings, confronted with the technical, social and political dynamics of innovation, at times even driving the agenda Joint collaboration to create a desired outcome
Table 1 - Comparison of research approaches [2]
The Living Lab methodologies are based on an intensive collaboration between partners to enable the co-creation of services and products. This was already proven during our work on the WP4 use cases by showing a number of advantages such as an effective way to establish trust between SMEs which is essential in B2B relationships and usually not easy to attain: e.g. you could rely on the local Living Lab having the knowledge of and contacts to reliable local partners, having checked them before inviting them into a new business relation. It also supports continuous innovation driven by users which is in the best interest of the collaborative SMEs.
The close collaboration between SAP, the SMEs that are part of FIAPAL Living Lab (CENI and Imeguisa) and YDreams, with weekly conference calls where all the stakeholders presented the progress in the implementation of the use cases and discussed technical issues, leading to the co-creation of the final solution that was implemented in both use cases. 3.4.1 Living Lab Methodology Process In line with what we stated under 3.3.2 we would like here to point out the systematic approach how existing knowledge and methods together with new methodical experiences were discovered used over the entire use case realization and execution. Design • •
• •
Basis used the already implemented use cases at SAP LL
Discussions conducted by Fiapal experts with Ydreams, Imeguisa and CENI regarding what equipment, how to connect to the MDI and what were the output requirements. Validation with SAP
Direct involvement of the end users for UI interface definition
Implementation Deliverable 4.4 Public
17
Final Version
Apollon – Deliverable D.4.4 • • •
Implementation team settled with team members from Ydreams and SAP
Installation and customization of the MDI platform in close and direct contact between team members. Regular feedback on site by Fiapal and with weekly conference calls
Execution •
•
Development of agents by Ydreams in close and direct contact with SME teams Regular feedback on site by Fiapal and with weekly conference calls
Support and Maintenance •
Local support assured within the local eco-system – Fiapal for the overall coordination and specific manufacturing equipment context and Ydreams for the MDI and use cases´ issues. Specific MDI incidents addressed by Ydreams directly with SAP LL
3.4.2 Webcam Tour method description Customers always ask for references and showcases in a real-world setup of technologies and services they are interested in.
For cross-border businesses it is sometimes very difficult for both business partners to either get sufficient information about the technology offered by a provider or to find out about the real requirements of a customer, as the involved companies are far away from each other. There are travels required either to visit each other or to meet at trade fairs, to get a better understanding of the needs and the potential value, which implies high costs, you are usually trying to avoid in early stage investigative actions or negotiations. The combination of video and audio for online demonstrations in a live and interactive mode is therefore highly of interest.
The SAP Research Future Factory team installed a webcam at their premises so that SMEs from Portugal could get a detailed insight into the capabilities and specific scenarios by following a guided tour. With the web camera being able to offer a 360° view into the SAP Research Future Factory the colleagues from SAP Research performed several Live video and audio streams that are qualitatively almost equal to onsite guided tours. The feedback and acceptance of these webcam tours has proven the right direction of our investment into such a new method. People that are not able to visit the Living Lab in person got also a clear view into what it is offering or working on and
Deliverable 4.4 Public
18
Final Version
Apollon – Deliverable D.4.4 therefore felt confident in starting a collaboration without having Face to Face meetings in advance.
Actually we are not just using the webcam tours for the WP4 purposes but also brought it to the next level of dissemination by interacting with the colleagues from WP6. This means that webcam tours are now also offered to a larger audience in order to gain attraction from new potential partners.
4. Evaluation of experiments and Lessons Learned Despite the distance and the different environments the Living Lab eco system assured the required conditions for a fruitful cooperation between entities.
On one side the large enterprises have a better ground for the evaluation of their products by executing tests that are done in a transnational test bed setup.
On the other side there are the SMEs that are working in (using) the Living Labs, by participating in the product development, -tuning and -debugging and which are finally front runners too, as their technology is used for new innovations in very heterogeneous environments to which they usually wouldn't have access to.
Did we face problems and bottlenecks during the project? Of course we did, such as software bugs, missing instructions, equipment missing data, poor equipment knowledge or missing technical data were the main examples.
But all these were overcome with a direct and transparent communication between SAP and Ydreams´ teams with focus on the problems to be solved.
Fiapal assured technical support to the SMEs when needed due to their restrictions in resources. Also managed the project locally creating a sense of urgency; this has been paramount to make it happen (assure progress and meet the deadlines). As lessons learned: •
•
•
Implementation of use cases in different contexts is proved to be possible;
The Living Lab eco system assures the required conditions for product codevelopment;
Feedback to the SAP Research Future Factory from SMEs, Fiapal and YDreams enabled the SAP Researchers to improve the MDI platform prototype in an expedite way
The cooperation model and the successfully implemented use cases were the required guarantee that reproducibility is possible for future projects.
4.1 Assessment of SMEs activities and scalability Energy monitoring use case
Deliverable 4.4 Public
19
Final Version
Apollon – Deliverable D.4.4 The use case, as described in D4.3 is fully implemented and is being used on a daily basis at Imeguisa. Energy is monitored for the complete plant and in two specific equipments. Now it is possible for this SME to evaluate peaks of consumption during operation and plan the rationalization of equipment use. Additionally the evaluation of potential energy savings is now possible. This use case is ready to be implemented in any SME. Asset viewing use case
This use case is fully implemented and used regularly at CENI. CENI intends to further develop the use case by introducing simulation capabilities. This will be interesting for didactic purposes and will be a reliable basis for future development activities. This use case is ready to be implemented in any SME with adaptations to the specific equipment.
4.2 Assessment of Living Labs network scalability Over the time, the established network of the Living Labs from Portugal and Germany became very strong and mature. The involved stakeholders setup clear processes and guidelines to execute the identified use cases. Figure 5 describes the infrastructure built. • • • •
support personnel availability (during business hours)
support message priority (high, medium, low) message response time (within 60 minutes after message sending)
fix rate (how often goes information forth and back until the problem is solved)
Figure 5: Living Lab network with connected SMEs
Multiple SMEs were able to work simultaneously through the Living Lab network regardless of the location where they are based.
For the first two use cases we used telephone / web conferencing to drive the knowledge exchange complemented by web container tools to transfer large software packages being either the software used as such or the necessary documentation. Deliverable 4.4 Public
20
Final Version
Apollon – Deliverable D.4.4 When it comes to larger or even multilateral projects we definitely need more sophisticated tools that facilitate the business identification, business generation and finally the business execution and maintenance of the solutions built. An IT based collaboration platform for both - service providers and service consumers - needs to be put in place. This collaboration platform should not just act as a marketplace but should also allow to exchange any kind of information (structured and or unstructured) that helps to understand "my" business partners.
Whilst the main focus of trading in the services industry is on electronic services (e.g. web services for electronic device integration, remote maintenance services) an Internet-based platform or marketplace may also cater for B2B services that require local/on-site interaction (e.g. consulting or set-up of systems). Such a trading platform or marketplace could provide support for • • • • • • • • • • •
Describing a service from a technical, functional and business oriented view (e.g. pricing, technical access specification, usage, regulatory and legal restrictions) Describing und publishing the request for a service, help, support… Matchmaking between service offers and service requests Trading of software modules developed by independent software and service providers Offering and selling the software and software modules via a web channel (web shop) Deploying a service electronically into a service runtime Finding local partners providing relevant on-site interaction with a user/customer Finding market-compliant local technical components Keeping track of the service implementation and usage Allowing to certify service offers incl. their service providers Pricing and billing of the goods and services traded via the platform
Thus the next months have been re-planned for the exploration and adaptation of such a platform [3] to evaluate its potential for business collaboration between the partners by using the use cases from the first phase of the manufacturing experiment.
Large software companies like SAP, Microsoft and others have these collaboration platforms in place since many years. The point is that these platforms are focusing on the software solutions delivered by the companies hosting the platforms. They also provide trust building methods and tools like certification programs for system integrators and/or independent software vendors. Certified services are well accepted at customer site and even a "must have" in order to survive the competition.
Beyond that what's might needed is a platform that includes any kind of software / hardware that customers are seeking and respectively their counterparts are providing. Deliverable 4.4 Public
21
Final Version
Apollon – Deliverable D.4.4
5. Summary For the project time being - and beyond - we always have to distinguish between two kinds of cross border activities.
The ones that have to do with the "build up" of a domain specific Living Lab network - therefore the interactions between the different Living Labs and the interactions between the Living Labs and SMEs to identify measures, methods and best practices that then help to trigger and run the "other" cross border activities that are in focus of APOLLON which are the cross border interactions between the SMEs as such. We believe that the Living Lab network that we have built so far heads into the right direction to facilitate SME businesses. Proof points are the facts that both the stakeholders from Germany as well as from Portugal have the same understanding how a Living Lab network should appear as an instrumental network.
As stated above - a common list of requirements was put together which will now be transformed into an internet presence which should work as a marketplace and collaboration platform at the same time. Details on the set-up, the collaboration and the trial will be found in D4.5. Literature: [1]
Apollon WP1 Questionnaire for methodology review sessions between WP1 and experiments WP4
[3]
Texo: Infrastructure for Web-based services (http://www.theseusprogramm.de/en/914.php )
[2]
Allen Higgins and Stefan Klein, "Introduction to the Living Lab Approach�, 2011
Deliverable 4.4 Public
22
Final Version