Keywords

1 Introduction and Challenge

PLM has become a widely-used concept and strategic component in today’s industrial companies. Moreover, it is part of an engineer’s daily business. Understanding the concepts of PLM will help developers to build sustainable products and contribute to commercial success of their company. Therefore, HSR (university of applied science of Rapperswil) and probably many other institutions consider PLM as a fundamental part of engineering education.

Yet, understanding why an industrial company needs PLM and how PLM affects an enterprise is challenging. It needs broad knowledge reinforced by good examples. Engineers need to understand the details (e.g. how their decisions affect other connecting parts, electronics or software), but also understand the big picture (e.g. understanding impact on services and the business model, be aware of subsequent processes, etc.). With increasing complexity of products and organizations, more disciplines are involved in product development and communication becomes essential. Increasing pressure on delivery time and production costs or concepts for digitization also force engineers to think outside their specialized domain.

In the educational environment at HSR we want to prepare our students to master these challenges. In the core disciplines we aim to advance them to level 5 or 6 according to Bloom’s taxonomy [1]. Thus, they should be able to draw their own conceptual decision (e.g. on a concept of product architecture) and be able to justify and stand this decision.

However, we discovered that these real-world situations can only be solved in a reasonable amount of time for limited problems. The bigger the complexity of the situation, the bigger the gap between theory and reality (see Fig. 1). Consequently, it takes more time to understand the problem and its constraints. Unfortunately, time in an educational environment is limited. Therefore, we were looking for a concept, where students need less time to understand the situation around the problem, but still are exposed to a reality-like situation that allows problem-based learning and reflection as suggested by Mazur [2, 3].

Fig. 1.
figure 1

Growing complexity creates a bigger gap to be closed with a transfer example.

Full size image

The obvious solution to close this gap in the context of PLM would be to create a company with its products, organization, processes, and tools. A company where students can gain practical experience, investigate concepts, and get immediate feedback from trial and error. An example that builds up from basic to complex and allows the students to get familiar with, maybe even over several semesters. It should allow to connect the topics and issues from various courses.

Neither a product nor an industrial company and customers for such an attempt existed. But continuing to teach such a dry, abstract, and complex topic without the possibility to gain experience was no option. A different approach was followed: A platform where one would be able to experience all this complexity and deal with it. An environment where learning PLM is fun.

2 Didactic Approach

An essential concept of education is the transfer from fundamental principles to the problems of the real world [4,5,6]. Good examples and practical exercise can help closing the gap between those two [7] as shown in Fig. 1. Often such examples cover only a single problem taken out of context. Building examples for single topics and taking them out of context may help. Multiple such examples may complete the “bridge”, but with increasing complexity the chances to create a complete picture drop, as illustrated in Fig. 2. In addition, the more complex topics or problems get, the more complex education of the corresponding theory will be.

Fig. 2.
figure 2

Missing pieces to connect different transfer examples.

Full size image

Hence, instead of taking complexity out or isolating it, a large example that can cover many topics was considered. Inside that example, the different topics and aspects were sorted by difficulty to explain them and their constraints and their connection to other topics. It should help to develop the full picture over time with increasing complexity. It should allow reflecting new theory on a known environment anytime.

“Full stack” Example.

To solve the problem of these missing pieces a different method was found. Instead of explaining topics with new examples for every new topic one example for many topics was created, that aims at covering both the simple but fundamental, as well as the complex problems (Fig. 3). Students should be able to connect the conceptual dots of the topic themselves or with help of interactive reflection. Depending on the nature of the problem, reflection can be among peers, or accompanied by the teacher.

Fig. 3.
figure 3

One “full stack” example covering the majority of topics.

Full size image

Goals.

Another important part of building a bridge between theory and reality is to create a first-hand experience on what impact certain actions have. Therefore, apart from fulfilling a certain complexity and educational requirements the real challenge was to create an environment where “trial and error”, reflection, and practicing is possible. A setup where students can figure out and experience themselves the consequences of their actions with no risks involved and a chance to go back. We endeavor creating an environment for problem-based learning, where curiosity takes over [2]. Eventually, this leads to continuous development of the setup based on questions and theories from students and other interested parties. This will help to create a sustainable example that still is flexible to be adopted to the latest development.

3 The Setup of the Transfer Example

Our setup to build a bridge between complex PLM theory and the challenges in a realistic company can be divided in three major parts: a physical product, a business environment, and the relevant IT landscape. While the physical product is based on prototyping tools (Lego, 3D prints, and Arduino), the business plan, organization, and processes of the exemplary companies are based on real figures. Also, the IT landscape is mostly built with known enterprise solutions.

3.1 Product

The product needed to suffice these major requirements:

  1. i.

    First and foremost, the product needed to be a mechatronic product with enough structural complexity to explain the aspects of classical PLM and interdisciplinary engineering. Mechanical engineering students at HSR are confronted with all kinds of modules from electronics, mechatronics, and robotics. The approach of letting students use their knowledge and build something increases their motivation and even more important, their perspective on the whole product in terms of systems engineering and not just as single actors or sensors.

  2. ii.

    Second, to be able to explain theories around modularization and the complexity of configurations the product needed to be modular. In a second step the whole system was formed to become an assemble-to-order product. This then also allows to dig deeper into complex structure matters and brings some more focus to the selling process and the customer with his specific needs.

  3. iii.

    Third, to cover the business side and current hot topics of the industry the product also needed to be servitized. A decision was made to create a “Machine as a Service” business model around the product.

A pick-and-place robot was chosen as the product. The robot collects and sorts LEGO “packages” based on their RFID tag. To be able to quickly try out new concepts, new versions, or to just compare old to new without having to spend too much money, LEGO Technic was the optimal tool for this. Since our students learn programming on the Arduino platform, the control of the machine was implemented on Arduino with a “hacked” interface to LEGO (electronic bridges and 3D printed parts for mechanical interfaces to LEGO). A very similar product with a similar mechanical concept exists in real world which helps to create the final link to the real world (Fig. 4).

Fig. 4.
figure 4

The pick-and-place robot.

Full size image

3.2 Companies in an Ecosystem

To emphasize the importance of the organization, processes, and business models in relation to a product and to give students a wider perspective, two virtual companies were created. A company called “Sortic” that produces the pick-and-place machine, as well as a company called “Dropkick” representing the customer.

Sortic.

In order to show and discuss the impact and dependencies between product and business model the company Sortic offers two ways of bringing machines to their customers. One is the “conventional” way of simply configuring and selling a complete pick-and-place system based on specifications of the customer. The other way is to offer the complete system as a service and just sell the work the machine does. This way, the machine remains the property of Sortic and it is in their interest to increase the lifetime of their products.

Dropkick.

A company founded by a couple of IT guys who found a clever algorithm that finds the fastest route through a city. Using that algorithm, they started a small delivery service that offers pick-up and delivery to any place within a city. The cost of that service depends on how fast a package must be delivered. If it is not time sensitive, the package will be brought to a central hub, where packages will be sorted depending on the algorithm’s shortest and most efficient route through the city. This is where Sortics machine comes into play. As a start-up, Dropkick does not have enough money to buy a machine and as IT guys they do not want to handle machines nor recruit somebody that can. So, the service that Sortic offers is optimal for Dropkick.

3.3 Processes Coverage

The example aims at education of future engineers in the world of digitization. Therefore, from the very beginning, PLM was considered as a closed loop process that covers all the essential processes and disciplines around the life of a product as described by Kiritsis et al. [8] or Cerri et al. [9]. In our scenario, this holistic approach can be vividly transferred to the two companies of the eco-system.

Design and Development.

The core competence of Sortic is the development of automation solutions. Due to the nature of the product, Sortic follows a systems engineering process and develops towards a mechatronic product structure. Also, a modular architecture is essential to their success, since Sortic follows an ATO (Assemble-to-Order) strategy. Students learn how to translate market requirements into a modular product structure. The “machine-as-a-service” business model also pictures what development of a service product means and how it is linked to the technology or equipment. All data in the collaboration between development and operations is present in corresponding PLM and ERP systems. This allows also to explore typical change management tasks and taking decisions on actual data.

Sales.

The sales process of Sortic needs configuration. In this setup, the specific needs of Dropkick are applied on the platform product and finally result in an order BOM (Bill of Material). In this process, the view of the customer and technical constraints of the platform must be matched. In addition, students can be challenged by requirements from Dropkick, which are not foreseen in the ATO concept of Sortic. This allows debating if the new requirement should be sold either as an ETO (Engineering-to-Order) component or become part of the platform or if it should be denied.

Production.

Sortic has a need for production management. For students of industrial engineering, the engineering BOM is given, and they must create a production concept which covers issues like:

  • Which assemblies can be produced in Kanban?

  • How will the final assembly look like?

  • What is the cost for different lot sizes?

Mechanical engineers will meet a given production concept and get feedback, on how well their product structure approach fits the thinking of operations – again material for intense debates.

Sourcing.

Some parts of the LEGO/Arduino model (e.g. the motor or the base plate for the robot module) can easily be upscaled to industrial products. With this information, different sourcing strategies can be investigated and “tested in the wild”. Because Sortic does have a business plan and a realistic sales plan, all necessary figures are available. In some cases, students even propose design optimizations for cheaper sourcing.

Service.

As mentioned above, in our scenario Dropkick did not buy the machine. They only buy machine hours, or more precisely they buy “sorting capacity”. To achieve the promised percentage of uptime, the Sortic machines were designed towards condition based monitoring. Typical maintenance scenarios can be tested and the importance of installed base data and the product history become obvious. In more advanced courses, this scenario also allows to experiment with IoT and machine-to-cloud communication, and predictive maintenance.

Innovation.

The generalization side of the closed loop model has not yet been integrated into the transfer model. Future work will be done on the feedback loop from data generated by real instances of the model leading into new design decisions. We envision many of these models, maybe even adopted by other universities or institutions, to create actual big data.

3.4 IT Tools (in the Landscape)

Around the product and the companies, a complete IT landscape was set up and configured to show how tool support, but also constraint typical business processes. Our IT architecture reflects a typical setup of a company with a higher degree of PLM maturity.

During product design and the different engineering processes the central hub and the single source of truth is the PLM system, in our case “Aras Innovator”. For the development process “Siemens NX” is used as an M-CAD, Fritzing as E-CAD, and versioning tool “Git” to store and manage the Arduino code base. Additionally, the software “Simio” is used to create different kinds of simulations for internal use as well as for customers. These tools all store their data in Aras.

To create customer specific products and orders in the sales process, a plant configurator is used (“PX5” by Perspectix). It is directly connected to the ERP system. For the operations processes, a cloud-based ERP solution called “myfactory” was fully configured and established. One major advantage of this cloud-based approach is the possibility to create copies of a complete setup in a couple of minutes. This allows to give each student his own ERP environment.

To interface the different solutions (particularly for release and change management), a web-services based architecture was deployed and linked with “NodeRed”, a visual programming tool that allows fast prototyping and easy connection of a large variety of communication protocols.

To create digital twins and link the machines with all their data to the cloud, a variety of tools on Microsoft’s “Azure Cloud” was introduced. This allows to follow novel concepts such as machine learning with neural network and other analytics tools. This, however, is currently part of our research and covered by student thesis, not in lectures.

4 Implementation in the Educational Environment

At HSR the setup explained above has been implemented. It runs under the name “Lifecycle Lab”. This Lab is a place where you can experience all the processes by actually doing them and figuring out what impact certain actions can have. It is also a place to make everyone aware of how important it is to take care of your data and how you can generate value and advantages if your applications and tools are properly configured and work as intended.

Learning units typically consist of theory, transfer, application, and reflection. The Lifecycle Lab offers building blocks to create tutorials for transfer, execute exercises in the lab environment, and allow reflection in the full context of Sortic and Dropkick. Based on the situation, it is up to the teacher if he chooses and inductive approach and starts with theory or to start with a tutorial in the lab environment and builds up theory in a deductive way. In either case, examples from real world will complete the picture. These can now be isolated, since the transfer example allows to create the links.

4.1 Application in Courses

The fictive companies Sortic and Dropkick as an example for the real world quickly found a partial introduction into many courses starting from the first semester and reaching into a specialization course for PLM implementation practice. Figure 5 gives an overview of the courses that interact with the Lifecycle Lab. Particularly the interaction between industrial engineers and mechanical engineers around product architecture and production management is worth mentioning. Initial frustration of mismatching approaches from both side hast the potential to turn into common understanding for each other’s needs.

Fig. 5.
figure 5

Education Courses

Full size image

Apart from the regular education courses, a post educational course for PLM responsibles in the industry is held every summer. In some cases, there is also a special training program for a specific company. In this context, the Lifecycle Lab proofed to be helpful in the opposite way. It allows to easily step out of the constraints and maybe frustration of the customer’s situation. Thus, concepts can be discussed with less emotions and therefore in a more objective way. After all, it’s just a toy.

5 Conclusion and Outlook

The chosen setup with a product and all the tools around it and consistent data flows has proven to be a good base to explore different topics along the lifecycle of that product. The “Lifecycle Lab” can make you aware of details, of major communication issues or the pitfalls of digitization. Even experienced PLM consultants are eager to try out new ideas on our model and gets fast results. Building up the lab was also fertile journey for the team doing it. It created debates about concepts, which were as real as in any PLM project, especially between the mechanical perspective and manufacturing.

5.1 Sandbox for New Theories

There are several points where the setup of the transfer example has proven to be extremely helpful. One of which is the possibility to quickly create new products, modules, or variants thanks to LEGO and 3D-printing.

The lab allows to understand how processes and data around the lifecycle of products are linked. For example, it can be observed, how new variant in the product architecture affects production, sales and service on the level of processes, but also on the level of data. It acts as a simulator to test different concepts and understand their consequences. Eventually, it also serves as a platform for research to validate new and uncertain PLM concepts.

The setup also proved optimal for continuous development by advanced students along with bachelor and master thesis. Different aspects of PLM, product, and business development can be refined and missing connections of the dots in our example can be closed. Especially in the field of “predictive maintenance” different topics have been explored and implemented into the lab which can be used to show different approaches of connected products.

5.2 Footprint

The transfer example of the LEGO robot started as an attempt to find a better, bigger example to explain the complex theory of PLM. Nowadays it’s much more than that. Professors and assistants from different areas and disciplines want to join and contribute to the project. From different perspectives, they see the lab as a good place to sensitize students as well as customers how interconnected different topics are. Often creating value out of PLM requires an interdisciplinary effort.

A positive effect was also achieved in terms of a common vocabulary. All stakeholders in this collaboration started to use common language and built up an understanding for each other’s perspectives - the fundament of sustainable collaboration.

5.3 Next Steps

After the first feasibility experiments where the robot sent sensor data to the cloud and first discussions around “digital twins”, it became clear that one possible next step would be that similar setups could be started on different places all around the globe. They would clearly profit from each other. Each setup would produce data that could be used for many existing and new theories. The data from one machine could improve the setup of another one, physically or software wise. As an open-source project, everybody who wants to contribute has the opportunity – the possibilities seem endless.

Ultimately, the knowledge gained from “playing with toys” in a large scale would be solid enough to be applicable not just in education, but also in industrial challenges. Current and new topics (digitization, industry 4.0) can be tested in our lab and the actual application inside a company becomes cheaper and less risky.

Eventually, without realizing it, students that contribute to this project would find themselves in a real global collaborative and interdisciplinary development scenario. However, there is still a long way to go.