Product Life Cycle Management

Product lifecycle management (PLM) is a business approach to manage product data and information throughout the entire product lifecycle, from initial concept to end-of-life. A PLM software does this by integrating people with processes and technology. [1]
PLM helps with getting all stakeholders on the same page, by giving access to the right documents. Making sure that people only get the information that is directly involved with them. This helps by achieving an efficient and productive environment. Especially when complex stakeholder structures are implied in the process of, for example, product development. This potentially gains companies a competitive edge, by reducing product development cycles and costs while improving quality. [2]
An important integration within PLM are systems like computer-aided design and enterprise resource planning. This could work within the same company. However, it is important to note that a common issue firms face is the lack of interconnectivity with other enterprise information systems, and the limited financial resources of small to medium enterprises can restrict their access to costly PLM software. [3]
By connecting PLM with software that embodies this vision, it is possible to benefit from the strategic and operational benefits that are offered. This will decrease the time-to-market and improve the quality of products, if well operated.

Introduction

In this assignment, a bigger company creating a new blade and yaw system for their windmill is simulated. The main focus here is to use a project lifecycle management (PLM) software to organise the project. There are many roles that should efficiently work together, see the data they need to see and no more. PLM software is an efficient way of organising the teamwork in bigger companies, but can be difficult to set up and understand. The PLM software that is used is 3Dexperience from D’assualt systeme. In this project, not only the exact working of this specific program are learned, but an understanding of PLM systems as a whole is created. The assignment’s secondary objective is to re-design a wind turbine from the scenario that could happen within an engineering company.
The steps that are taken in the PLM software are based on the scenario that is represented in the figure below. This picture explains that steps should be taken and who should approve different actions to make sure that the right people get informed with the information that they need for their part of the project. During this report, the structure will be explained to show how it is implemented within this project.

The General structure of the change process seen in the picture above is a simplification of the Version that can be seen below. In the more elaborated version of the change process seen below all the steps needed for the change process can be observed.

Scenario

During this project a company is simulated that develops and sells wind turbines, manufacturing is outsourced. A wind turbine is currently released onto the market. However, improvements can be made to the wind blades and yaw. A project managers raises issues on different parts of these assemblies and proposes a redesign of the blades and yaw. This process will be executed by an internal design team making use of the full PLM change process, CR with CA governed by CO.

Roles

To simulate the internal structure of the company different roles are defined. Each of the (four) group members in this project will be assigned to represent multiple roles within this simulated company during the PLM process. In the table below the defined roles can be observed and who is assigned to each role.

First, an issue is raised by either an engineer, expert or product manager. In this case, the issues were raised by the project leader. This process starts in the 3D markup space, where comments can be placed on the parts that should be changed. This is helpful as the 3D markup acts as reference point for what the exact issue is, and which parts of the product are involved.

Mark up

Two separate initial 3D markup’s were created, one for each problem (blade, yaw). The 3D markups for the blade and yaw can be seen in the images below accompanied with their corresponding comments.

Blade

Comment: Blade shape is not optimal for best wind power/electricity yield. This needs to be improved.

Yaw

Comment: Yaw is not optimal for smooth turning. Due to this proper orientation is often difficult. Therefore the Yaw needs a redesign

Each of these markups can be used within their respective processes to act as clarification of what the exact problem is and which parts are influenced by this problem.

Creating the issues

Two issues were created from the 3D markups, one for the blade and another for the yaw. Each of these issues is assigned to a corresponding change manager who will manage the coming steps in the change process.

Blade

Jop was assigned to the issue of the blade as he is the change manager for the improvement of the blade.

Yaw

Victor was assigned to the issue of the yaw as he is the change manager for the improvement of the yaw.

For each issue a change request (CR) is created and defined by the corresponding change manager, as can be seen below.

Impact analysis

The change manager creates impact analyses (IA) corresponding to different experts, such as a financial expert or material design expert. Experts receive their respective IA's and files and are asked to give valuable insights on what the change process would mean for the product and/or company from the perspective of their expertise.

Approval routing

After all impact analyses have been written by the experts, the change owner should approve the impact analysis, simply checking whether all analyses have been composed. The project leader has a more in-depth look at the analyses and is the first to assert whether the impact of changing the product is feasible and worth the risk.
The final approval should come from the manager with the authority to do so when all risks are weighed against the potential benefits. If all involved parties decide the change is acceptable, the CR will be approved by them through the routing that can be seen below.

Gantt chart

After the change request has been approved, the project leader makes a planning for the whole project. This is done by making a Gantt Chart using the project management application in 3Dexperience. In this chart, the project leader defines milestones and tasks to then define their order and dependencies. During the project, progress is routinely checked to make sure that no part is lacking, 3Dexperience also notifies involved users when deadlines are near or overdue. The initial panning can be seen in the Gantt Chart below.

General planning and milestones

Here the general span of the project can be observed including the different milestones within the sub-projects.

Sub-projects

When looking at the different sub-project's different tasks, milestones and dependencies can be observed. Using this overview the project manager can see all planned activities for a certain project in one overview. Furthermore, task assignment overviews for each user can also be found. This overview can be used to better distributed work over the project group.
In general, the project management app provides an easy way to plan, manage and overview one or more projects.

Blade project

Yaw project

The process is now completely approved, and gets started according to the planning. First off, the final step in the set-up process should be done; making the change orders (CO). Two change orders are made, one for the blade optimalization and one for the yaw system. Both these change orders contain change actions for design, mechanical and simulation.

Approval routing

After the change actions (CA) have been executed, the change order can be approved using a routing. Said CA’s are furter described in the next section.
As the CA’s have already been approved by relevant experts, the CO only needs to be approved by upper management. When the CO is approved, the product is released and the CR’s and initial issues can be completed respectively, ending the change process and therefore concluding project.

The change actions created under the change orders are linked to the specific engineer who should perform the task. When the engineer is done with its part, it is sent for approval to a domain expert and then to the project lead.
According to the created planning, the design change action should be done first, then the mechanical one, and finally the simulation change action. This could however be changed as the process as a whole is an iterative process that might require multiple versions.

During the execution of the change process the engineer selects the CA when editing the CAD files. This way the changes to the relevant files will be recorded under the CA as applied changes. These changes can be reviewed, approved or reversed in an easy way.

Revision

As defined in the scenario, the company already has an existing wind turbine released to the market that will undergo the change process. When applying the CA’s a new revision of the changed parts is made. These revised parts will then be released to the market once the full change process is completed (CO is approved).

Approval routing

The approval of the CA’s is done using a routing. For this project the realized changes are first reviewed and approved by one or more experts in the respective field. After this the project leader will review and approve the work as final approval.

Through this change process the different improvements to the wind turbine blade and yaw were realised. The improvement process is defined, executed, reviewed and approved by different parties' through the approval routings of the CA’s, CO’s, CR’s and finally the initial raised issues. These improvements and validations made to the blade and yaw are documented in this section.

Blade design

The main goal of the blade re-design is to make it more efficient, this can be done by optimizing the aerodynamics of the blade. The design engineer’s sketch focuses on improving the cross-section of the blade, the shape is inspired on a water droplet shape. Since the overall shape of the blade will be changed, the connection to the rest of the assembly should be changed as well, this concept is also worked out in the sketch.

Based on the concept design of the blade the nomenclature of the blade section was defined, as can be seen in the SOLIDWORKS sketch below. The cord length and pitch angle for the different blade sections was determined using the given values in the course description of the PLM project. These values can be seen in the tables below.

From the pitch angles and chord lengths the new blade was modelled in SOLIDWORKS. Additionally, the connection piece for the rotor was altered to fit the new rotor blade using a round connection with a key insert to assure the proper orientation of the blade.

Blade simulation

A flow simulation was performed to evaluate the proposed design changes. The simulation was initially conducted on the baseline blade design, and these results served as a comparative guideline for the simulation of the proposed design. The flow simulation on the proposed design revealed a reduction in drag forces and an increase in lift forces. The detailed results, including drag and lift coefficients, can be seen in the table below.

After adjusting for the differance in coordinate systems the following Drag and Lift are obtained.

Yaw design

The yaw system of the current wind turbine gives too much friction, this is an issue due to the wear of the metal pieces and losing energy. The new concept from the design engineer shows a possible solution by including a bearring in the design. This, so called thrust bearing is placed between the axle and the nacelle to reduce friction caused by the rotating pieces. The axle has been re-designed, to accommodate for the bearing. The length of the axle has increased and the width of the flange has been widened, both these changes make sure that the bearing fits on the axle.

Yaw motion study

A motion study has been performed by the engineer to check if all parts fit and to see if the required rotating has been designed as intended. The study shows that the changes, in theory, should perform as designed. Since the new yaw axle is very similar to the original one and no extra protrusions that could cause obstructions during rotations were added, this was very much within the line of expectation. After the simulation has been approved, the technical drawings can be sent to the manufacturer to find out if the changes could also work in practice.

Product lifecycle management software, in this case 3Dexperience, has been used during this project. The use case of this project is to simulate being a company that has to improve their wind turbine to increase the efficiency of the blades and to reduce the friction in the yaw system. This whole process is done by using the PLM software to keep track of the planning, the changes and the approvals that are needed in a company to perform these changes.
Using this software gave a valuable insight in what it could potentially look like and to understand the complete change process. By closely following the proposed PLM process, the project and the changes went through all necessary steps and approvals, creating a solid ground to realize changes and to streamline the process.
Using a PLM software could, after learning from this experience, prove to be helpful for small and medium-sized companies, since the whole process is streamlined and well-organized and being able to have all potential tools available in the toolbar. For larger companies, the PLM software should be a necessity. Being able to organize, streamline the process will be helpful. The function to only show the necessary files and tools feels crucial for large companies, to make sure that employees do not get too much or too little information to be able to perform their job of the project. 

Reflection

At first, the chosen software 3Dexperience, seemed like a good fit for both the project and the experience from the group since all previously used other software from the same company. However, the software seemed to have a steeper learning curve than expected. The process and theory behind PLM was explained, but implementing this in this exact PLM software gave some troubles, as expected when learning a new software.
The process that was used during this project was based on the process explained during the theory part of the course. This process seemed to be beneficial and structured, which helped with project management and change management. The small group size of this project caused some issues since some group member, for example, had to be both CEO and change manager. This means that due to some approval routings, the same person had to approve twice for the process to continue. These kind of scenarios will not happen during projects in larger companies, but since SMEs could potentially also use the project, it might be interesting to see if there is an different routing that these companies take to make sure that the approval process does not only go through one person.
During this project different problems were encountered in the change process. One of the main problems has to do with PDM. A lot of problems were encountered with saving, duplicate files and maturity states. This was most likely caused by branching the original product assembly from another space, causing problems with permissions to the files. This problem could have been prevented by downloading the files locally and uploading them to the new space instead of branching them. From these uploaded files the relevant files would be revised during the CA’s. In the end this had to be done this way anyway as the branched parts could not be put into frozen anymore due to lacking permissions.

Another problem was with the aerodynamics simulations. Due to a lack of knowledge in the field it was unclear whether the new blade was better or worse. This caused a lot of time being spend into figuring out the aerodynamics of the blades while this time have better been spent in the PLM process.

References

[1] M. David en F. Rowe, “What does PLMS (product lifecycle management systems) manage: Data or documents? Complementarity and contingency for SMEs”, Computers in Industry, vol. 75, pp. 140–150, jun. 2015, doi: 10.1016/j.compind.2015.05.005.
[2] S. Terzi, A. Bouras, D. Dutta, M. Garetti, en D. Kiritsis, “Product lifecycle management – from its history to its new role”, International Journal Of Product Lifecycle Management, vol. 4, nr. 4, p. 360, jan. 2010, doi: 10.1504/ijplm.2010.036489.
[3] P. Soto-Acosta, E. Placer-Maruri, en D. Perez-Gonzalez, “A case analysis of a product lifecycle information management framework for SMEs”, International Journal Of Information Management, vol. 36, nr. 2, pp. 240–244, dec. 2015, doi: 10.1016/j.ijinfomgt.2015.12.001.