ALM Meets PDM: A Journey From Requirements to Realization

00:00 Okay. A warm welcome from the company Festo to our journey from requirements to realization. We want to talk about ALM and PDM. My colleague Peter and I will guide you to this through this session. And first of all, I want to talk about the agenda. We want to introduce Festo to you. Then we want to talk about the application themselves, how they work in our workflow. And Peter will show you a practical example within Festo how we use ALM and PDM.

00:37 So first of us, I like to introduce Festo to you. Festo was founded 1922 in Esslingen am Neckar. This is a small or big city near Stuttgart, which is in the south western part of Germany. So first we started with wood tools and we recognized the usage of pneumatics very fast. So since 1955 we started to use and also to develop and produce pneumatic components

01:11 and systems. So in this way we were able to bring the first valve terminal on the world to market. That means we we combined pneumatics with electrics. To get the customers solutions. 30 years later, in 2017, we were able to launch the Festo motion terminal. So in this way, we are the leader, one of the leaders of pneumatics.

01:41 Another big thing is the Bionic Learning Network. We have a cooperation with universities, institutes to learn from the nature, to get the knowledge into future technologies. So this is another big thing for us. But we recognized also that the knowledge of pneumatics needs to be trained internally for our employees as well as for our customers. So this is why we founded the Festo Didactic and we use our training systems all over

02:14 the world, also in institutes, universities and schools to train the experts of tomorrow. So this is what we do. We have in 61 countries around 21,000 employees. And with a turnover of in 2022 of €3.8 billion, we are good in market. Okay. We are big in automation, live tech. And as I told you in Didactics. We have a catalog with around 30,000 products.

02:48 But we also have customizable customizable products. So as you know, the drives, you have it in different lengths. So in this way we can customization too. And also we can offer individualized solutions and our goal is a delivery within 24 hours. So our market, wherever it needs to be, anything picked, moved and placed Festo can help you. So to be fast. But our main market is the automotive industry and also the food and packaging.

03:21 So this was about us. Another thing is let's talk about the development network. As I told you, in 61 countries we have our branches, but in a few of them we have techs. That means in here we have the also the developments of our products all over the world. Okay, so. So now you know everything about Festo. Now let's talk about the applications. We follow the strategy idea to solve.

03:55 We have an idea of a product and need to bring it fast to the market, to the digital shop floor. In this way, we need to talk about the product development on the one track and on the other track the order fulfillment. And this needs to be covered with different systems we have in the product development, the PLM system for the order fulfillment, the ERP and for the digital shop floor, the Emmys. So we need to take a deeper look now into our PLM,

04:26 especially in the beginning of the development where ALM meets PDM. So what is ALM within ALM? This is Codebeamer for sure. At Festo we covered all the specifications of the products, so the stakeholder requirements are covered in there and also the technical part of the specifications. All this needs to be done in compliance with the given standards. So the standards for the whole process needs to be covered and also for the tests within

05:02 for the for the products. So this is covered in Codebeamer. And the other system we use is Windchill for the PDM. And in here we have the storage of the 3D and 2D data. So the technical data of our products, it means we have the models, the 2D drawings, the simulations, data sheets, but also as a product, all the attributes and parameters. So we talk about weight materials and so on.

05:32 All those information are covered within Windchill and we have also the viewable of all documents in there. So we get all the information, the technical information. Now let's go back to Codebeamer. The history within Festo of Codebeamer. We use it for our product software development since 2012. But later on we also recognized it's a good thing. So we need to use it for our hardware, for the product development.

06:05 And so we introduce it in 2018. By the way, since 2008, we use Windchill. So we started with Windchill and then adopted the ALM and also through since 2019, we have the Air Process automation organization and that also needs to be covered with the ALM. Right. So now we need to look into the workflow. How does the whole thing work? We have to pay attention of a few things when we go to the development.

06:38 We have the standards for the process. We have a few components that needs to be picked together with a development loop, and all this needs to be covered also in this agile process of the organization. And the other thing is we work global. So all those things needs to be covered up in our systems and that's. Why or how we can do it. So let's imagine we have a product manager, a customer,

07:12 talk to him or herself has any idea, and he comes up with the specifications of this idea and he brings it into Codebeamer and defines a specification. Any idea? So all the specifications are saved now in Codebeamer and now the product developer developer has or gets the idea what to do. There is the task and he needs to go to get a solution, right? So in our case, we use Creo to create 3D models and associated drawings.

07:47 So this is the technical describing of our product. So and this would be the solution later on that comes back to Codebeamer. At first, all the information needs to be stored in Windchill. This is our product data management. So in here all the technical information are in. We have the data, we have the attributes, we have the variables and everything in there. So this is the answer or the solution that the product manager gets back

08:19 because this solution is nowadays typed in to the requirements and so the product manager can go in, okay, this is the answer to my question, to my requirement. When we show you everything we do now. And later, will Peter show you how it works? Really? I have to tell you, we show you in which versions we work now. So this is our state now, and we work with Windchill version two,

08:49 12.2 and Codebeamer 21.9. So in this way, we need to work with a lot of screen capture screening and copy and paste to get those answers back to the requirements. There is no linkage in between Windchill and Codebeamer. Not yet. And this would be our big request for the future to have a linkage between this Windchill and Codebeamer to get the right answers.

09:24 Yeah. In any point in any state within the development when we want it. So now let's go deeper again. As I told you, everywhere you need to grab move place parts, you can ask Festo. And now we were able to bring our new Festo Cobot also here to this convention. And in this product we were able to add all our components

09:55 and to work together with this product. And by the way, Cobot means it's a robot that collaborates with us human beings. So come to Xtropolis, take a look at it. We have it. And in this way we can show you why, what we need to do. We need to add different ways. And I think that's the way you work. Also, we have the mechanics, we have the electronics, we have the software, we have the pneumatics in our way.

10:26 And we all need to add those components to get our product in the end, our working product. If we think of this product, we go back again to the idea we have the specification defined in Codebeamer. We need to have this code, but it's written down in Codebeamer and this is the database to create a 3D model. All those requirements needs to be covered. So back comes the solution. Also typed in to the ALM.

10:57 Again, with this idea we need to do for the development loop, we need to have also simulations. Does everything is everything calculated? Does it work? Will it work? So also therefore we have the database of the 3D models. The Ansys go back to Codebeamer After a sample production, we have maybe the first sample and we can go to the testing. And also here we have the database, the 3D model and the answer of the test cases Go back to Codebeamer again

11:33 and in this way we also have the validation between the simulation and the testing. So was the simulation correct? And the answer comes back again. We work on this idea and get a first solution . So but now we need to work agile. So that means we need to get better and better and better every iteration. So at Festo we, we use the Agile release train. That means every quarter we make a planning. This is our Pi planning and we plan in there for sprints.

12:06 So that means every four weeks we have a new sprint and within those sprints we define what needs to be needs to be done, what are the tasks within those next four weeks. So in this way we start with this whole development loop. Like I showed you before we work on this, we get first answers for our requests and we work within one sprint the tasks we need to do. But then the other sprint comes up and we rework

12:38 the whole thing, not the whole thing, but parts of this thing. And in this way we create another version of the specification maybe. And this means we need to have another variant or another instance of also the design, the simulation and the testing. So and this rolls on and rolls on. And in this way we get better and better within the Agile release train, right? So this is the other thing, the agility.

13:08 And then we have the global, the globalization we have here in Boston, the tech. So it could be Peter Box in the morning in Germany on anything he develops anything and then he calls Freddy and says, okay, I'm done for today. Go ahead, work on this part. And in this way we need one single point of truth. We need to have one access to the requirements and also to the data. So and this was now my part. I will hand over to Peter. He will show you the example.

13:43 Yeah, I'm Peter from the Robotics Development within Festo and I bring some flesh to the bone to things Catherine showed you before. First I will start question about the why. Why do we work like how we work? Why do we do what we do? And it's a simple question and also an simple answer. Yeah, we want and we need to bring the customer in the center of any development task. This allows us to focus on the important things with a strong demand of QCD

14:14 and simply said speed up, cost down. This is why we work Agile. That's why we work in a ALM tool and all this stuff. The question about the how, how to bring obsession, customer obsession to life, how to get this done in a You probably all know the Vuca world nowadays. They call it even Ebony world after the pandemic. So brittle, anxious, nonlinear and comprehensive part. And that's how we want to do this.

14:46 We have the customer in the center and we have a real focus on model based engineering and systems engineering, having the user defining some use cases, deforming some, some activities, and we combine different architectural views for getting some kind of functional architecture where we derive this requirements out of this. We have the product management working close with the customer, we have the engineers working close to the customer as this is really a key element to bring these parties together to make the most benefit out of it.

15:17 Once we have this functional architecture, we go into the solution mode. There we have the software, the hardware, the mechanics running out of this and all of this. We put this in our skate agile framework. So where we facilitate our API planning, where we generate and fulfill our features, where we pull our enablers out of this, this is how we work. So it's connect the lines for, for deforming a way forward within this connecting of the line. So once you have the build up, it's pretty nice, but you have to keep it alive.

15:48 It's nothing when you just have it. Once we are agile, we are changing, We change in fast, we change in often. So you need to make sure that you have a very good traceability. And this is starting on one hand with the stakeholder requirements which are really the top level of requirements. What we have deforming the top ten customer needs, so to say, and the surroundings and key factors you have to fulfill. Then on the next level you have the specification which is describing in detail what the solution to

16:19 the requirements is, what does it look like? And further down the line you have the test cases. The test cases we Catherine showed you, simulation is kind of test case and we have physical tests. You have automated tests to software tests and all this stuff as you prove the specification and then you have a full traceability down the line for all. For this you need some consequence system engineering and furthermore system engineers are just a few. Developers are quite a lot. You need systems thinking in every single developer and this is the the key task

16:51 for everyone when everyone is system thinking you have a huge room for for solutions and stuff and then you really create innovation. But how does it look in reality? So the question about the what come in to the robot itself. So you see in here, it's a technical principle of a six axis robot. You have six movable joints and you have six structure parts in between. And for our example, we'd like to keep it pretty simple.

17:21 We will concentrate on a very simple structure part. It's a shoulder part of the robot. I will show you in a minute. I have circled it around and what's the applicable for this? For this part. So you have stakeholder requirements, so top level requirements that you can link to this part. These are some, some pretty simple ones like temperature, some vibration resistance and some some. Form factors and stuff, but you also have as it's a simple part in a complex system,

17:53 you have subsystem requirements. So you have some geometric requirements, for example, from, from system architecture, how big it should be, what forces it should take. And you have interfaces to the neighboring part. It comes from somewhere, it goes to somewhere and it has to fit. It has mechanical connections or maybe a paramedic or electrical connections and software connections as well. And last but not least, you also have requirements from guidelines and directives. And this you never need to underestimate. Yes.

18:23 Because this in the end makes the difference between you get the certification from to for someone else or you don't get it. It's as simple as this. And a lot of you are in automotive industry where you have a lot of standards or in defense, you have even more standards. And for a complex system like robotics, you also have a big bunch of standards and directives you have to follow. One of them is the ISO 3000 849 for safety of machinery. And for this mechanical part, there are some some general principles for design applicable which describe you how you have to simulate,

18:56 what safety factors you have to fulfill and these stuff. So looking really in the realization, as you have learned, we're running in Agile. We had the first loop. We had a proof of concept robot. This robot was called Ronja, and we did a lot of pilot testing with this. So you see this, this bracket, the shoulder bracket, it's a machine one. It has some asymmetrical design. You see, this is the X one and it's a bit cranked out for the for the X two. And you see a lot of additional parts and screws for assembly of cover

19:29 and connectivity. So when you have a look work. Yep. This is how Ronja looked without her cloth and this is how ronja looked when it's pretty dressed up nice and shiny so you don't see the brackets anymore. But I want to show you the detail. So this is the the small bracket underneath is what you see in here. So as I said, we did a lot of pilot checks and customer checks. And within our scaled agile, our demo,

19:59 we we demonstrated and showed to our stakeholders and to key customers and stuff and get some feedback to this. And for sure we checked against our stakeholder requirements. So remember, these were applicable and how we checked it. Yeah, we checked it like I described before with our traceability. We have some specification I show you on the on the example of temperature. So we have an ambient temperature for operation. In the request we have a specification operating temperature described which we use

20:29 for all the simulation and all this part. And we have a test case set where it's detailed, described how we test it. There's a temperature curve, there's a timing to this. There is a test equipment assigned to it. There's expected results to this. And once you have run this successfully. Successfully to tick the box. And you're good to go? Yeah. And with the first prototype, we were already able to tick some of these boxes. For some, we had some question mark and cross checking

20:59 the feedback we saw that some of them might be not fulfilled at this stage. And at this point you always has two options. You optimize your product or you go in discussion with your product management and your customer and request and double check with the help of your prototype. In best case, what is really your need, what you want to do? For sure. We went to a design loop. It was the first part. So the design loop was nothing. Nothing special. The feedback from the prototype. What we had is we are too heavy. We are too bulky. One very interesting thing is reach was higher valued than payload,

21:33 so the reach of the robot arm itself is more worth more value of customer than the kilogram. It can. It can take away and take a round. And that's what leads us to a different design approach. And as we had some limitations in our reach and we had a lot of feedback from from building up the assembly for optimization, the cover fixation optimization, cabling and tubing and stuff. So we ran into this loop and you see the shoulder of Betina. Yeah. One of the key things where we were opened,

22:05 this part in here and over there for allow a better assembly for cabling and tubing. Everyone who tried to put a cable with the connector through a hole knows that this is limited and the connector always bigger than the cable. This challenges we now have we have open it. It's weaker in the structure, but we cover this with some inline simulation. We had the simulation partly automated already and cut this check that it's all good to go. What we also did is design the cost approach. We prepared the part for being a tool based part, not a machined one.

22:37 For Betina, it still was machined. We now have a symmetrical design, so we have increased the other structure parts to get more real reach. We run out of this asymmetric part and we have no additional parts and no screws for current assembly. And we follow some lightweight design approach for functional integration. So here are some pictures again from Burkina Without Betina, without the covers, and Betina with the covers, and we run with Betina in much more testing as we had proven some simulation.

23:10 We also run in vibration and shock testing and this was really amazing for the people as we have a big shock tester and it's running described sequence from low frequency with a high amplitude following increasing the amplitude or increasing the frequency and lowering down the amplitude. And you see that the robot is moving massively and suddenly you come to a point where the control loop becomes better and better and the payload itself gets more and more stable.

23:41 So the people first run a bit away because the structure looked a bit weak towards this shaking and stuff. But in the end it's successfully proven. So when we checked this information we see even more green ticks. It's all good. There are some question marks still on the compact design and also on fulfilling the ISO standard for the general principles as they were. No proof, but there most likely will be okay. We still got some feedback that we are still too heavy and the production feedback was also you can do even more and cost, you can always optimize.

24:12 So we decided to run another loop for Realize Gravity Die casting and optimize customer benefits and ensure the requirement fulfillment in total. As you know, when you have the first loops are quite easy, they are quite obvious, but when you nail it down further and you optimize, you go to the edge. You need to think about different approaches and need to think about how to to get this done for us. We have a strong, lightweight character in our self,

24:43 a strong mood also to the bionics in our stage. So we checked on bionic lightweight design. And what does it mean for this? For this part, we looked at the leaf of the lily for increase the stiffness of the part. So this is really massively and you see in the bracket itself, we adapted the structure of this leaf to get very lightweight but high, robust and stiff part in this. And some mechanical engineers, if we have some know the rule of matic,

25:14 how it a tree is withstand all the wind. And for this this is how this angle are distributed. These angles are nice. And this we adapted also to this lower part as fem simulation showed that this is the weak point. It's always the sharp edges, which are the weak point of the of the part here. You see. Then the final design, the robot is called Clarissa. It's a gravity die casting part with a weight of 940g nearly. We have still symmetrical design. No additional parts for the assembly and as I said.

25:45 We have the function integration and lightweight manufacturing for this one. You see the robot built out of it again without the covers and with the covers. And for this gravity die casting, we had some some simulation checks for proving that it's robust enough and you always have to consider blow holes when you go in gravity die casting and we CT scanned the angle. You see one scan going from from low to up and one from side to side.

26:18 The light parts are metal, the dark are holes. And when you come to a certain point, you can look over here in the upper thing, you see how the strut in the middle is got lost. So there is a blow hole. And we fed back this scan into our simulation to prove that our blow hole class is okay to to check that our process for manufacturing is okay. And also that with real data, with real physical parts, we are still pretty good in the safety factors for the for the for the stuff.

26:50 So then we checked and finally we are really good to go. So with this one we also were able to to prove the safety factors for the general principles of design. So this all in all worked in shadowed world. So we have the requirements and set in Codebeamer. All this information were handed over manually to the simulation, all this ambient part, the the forces and stuff. We had our living up and our CAD generating different versions and part.

27:24 We always sneaked and copy pasted into Codebeamer what the reality is at the moment. So imagine a world where you have only one single point of truth. We're outdated. Screenshots are no issue at all. Whereas no doubt which requirement that is fulfilled by which version of hardware and software. And their impact studies become some clicks wonder. I think PTC can make this happen. And now I'm finished with my presentation. You can.

27:59 Visit us at Xtropolis. We have the Cobot with us. Peter Hull is is here from the from the Codebeamer team who will take all these questions and. Get you with your journey on the integration and part. And here. If you have any questions. So if you have any questions right now,

28:31 here are the micros so you can come and ask anything. And also, Peter Haller will help you to answer the questions if you have any. When you intend to link the objects in Codebeamer with the objects in Windchill, what kind of object will you create and in which of the systems your your parts probably have many variants and many of those parts have the same requirements or many of the requirements apply for many variants

29:04 and they have them in common. So if you want to manage that variation, you don't want to create a new set of requirements for every instance or for every variant. So you need some abstract representation for that shoulder part. And for the next part you have also, and you can't replicate that for every part number that you create for the different variants. So how do you manage this?

29:34 At the moment we just manage this manually. So we just described this part. We have the different variants, what we are seeing and we the most likely or the line we want to follow, then we, we put this into Codebeamer and have this specification and the different models are stored and archived. So we have that's one of the challenges what we are seeing. So what, what how it can be solved. This is a question to PTC how they will get this, get this done.

30:04 Yeah, I think it's pretty good. Currently you're doing the traceability to the individual part number. Yeah. Not to a subsystem that is common for many part numbers. Not we start with a with a description. So with with the system design itself. So we call it the shoulder part. And in the in the Codebeamer we don't list the part number at the moment, so we just have a sneak of it and it could be whatever part number it is because the,

30:34 the real reality of the of the part itself is then in Windchill under the top level number and the top level number has has this bill of material in stomach and could have variants if we build it in an alternative parts or even not. So we have in the Codebeamer only the top level level part number. And then the bill of material management is in Windchill and the realization. Thank you. Thanks. Hey there. So I've seen on one of your slides you sort of artificially put some green check marks

31:09 to keep a track of your verification progress on your requirements. Now let's say you have multiple test results on your requirements. How do you keep a track of which ones are verified and which results are, you know, relevant to that requirement? Yeah, this is in the linkage of the test cases. So you have the status in the Codebeamer of the requirement and you address several test cases and then you need to to review and approve that this set is fulfilling. Then this this requirement.

31:42 So this is a manual review process. And when this line is done, then then it's settled. And when you successfully run this test case, then the traffic light changes. Then you get a green result and you get a test coverage. You can generate a report out of Codebeamer out of this and have a have a coverage of the of your tests so you can run automated reports in the Codebeamer which shows you this requirement is not tested. This is tested successfully. This test is is done. And when you identify that you have to renew a test, then you change this traffic light,

32:14 You set it from from accepted and reviewed and tested to defined or to review or whatever state you use. Okay. So it's a report that you can run requirement based to give you a traffic light status and each requirement. And what happens if you have multiple test results on that requirement like 2 or 3 are maybe failed, maybe they're exploratory tests and then you move on to a final verification test and you have one that's failed and then another one that's passed. Then then the requirement is not not proven. Then then you have it's only proven once.

32:45 Either all tests are unsuccessful or not. When every test is successful and you have to review, maybe it's the test not applicable. That's what I mean. You have always two options when you recognize along the testing and along the the analyzes of this testing afterwards that you went a step too far with the testing. And the testing proves more than the requirement. You have an unluckily cut of this test case. So to say you see it in Agile often that you cut your stories not not right and you can't reach it and you cut into fit it in your sprint and you do the same with,

33:18 with the with the requirements and the test cases. Then you go into discussion with the relevant managers and people and test groups and stuff and, and really check what is really necessary does. Disprove more than this requirement. If if yes, then you cut it differently and you take it out and you put it in another way. Or this requirement is not proven and you have to adapt. Thank you.

33:48 One more question. I didn't see Fmea in that picture. Is that somewhere. Not in this picture? Yeah. We have a different tool in a different tool set. And for sure we are in Fmea. We run system Fmea we run design Fmea we run a process. Fmea And this is all part of this input or as well, yeah. And defines the test cases. It defines the test cases as. Well as well, Yeah. Thanks.