PLM-Integrated Requirements Management

Alright, ladies and gentlemen, thank you very much. As introduced, my name is Michael Pfennig and I'm responsible for XPLM's business unit Process Consulting. I'm here today to talk a little bit about a project that we had together with our customer EGO, and Mr. Sven Egner from EGO is also here with me today to give a little bit more insight into the project and what his challenges are when it comes to PLM. From my point of view, requirements management is still something that needs to be improved, even if the concept isn't quite new. What's new is another concept for the early phase of product development, and that's called model-based systems engineering. I guess MBSE has been talked about a lot in the last couple of months, and it's also something engineers see as a promising endeavor to keep product and process complexity manageable. I would like to point out that there is another presentation today after the morning coffee break at 11:30. Professor Martin Eichner is going to discuss similar issues in the context of the Internet of Things and Industry 4.0. I'm going to listen to him and Let's see if we see each other there again. I hope our presentation is able to get the context straight and help to understand why we think PLM integrated requirements management is the first step on the journey to a model-based engineering approach. In my preparation phase for this presentation, I was asked what should be the focus of successful requirements management? And I said, well, probably one thing, Is clear, nothing changes faster than customer requirements. Here is an example of how over and over changing requirements lead to chaotic project management. I guess all of you heard about the outcome of this project and I don't have to further explain how bad this project is for the reputation of German engineering. By the way, it would be unfair to only blame the engineers. Involved in that project. The guys unfortunately had to deal with a lot of politicians, which I hope you do in your engineering projects not so much. So what is the lessons learned from the Berlin Airport? Of course, customer requirements are a moving target, but somehow project management needs to nail down the customer to certain sets or asset of requirements. This is nothing done too easy as you may have experienced, but definitely one of the key issues. All right, let's start with a quick overview on what we're gonna go through. First of all, I have some slides about our company. Then Mr. Sven Igner from EGO says a little bit about EGO and their products and their implementation of Oracle AGI EDM as their PLM system. After that, I wanna present a project we are having with EGO as the case study study. And last but not least, I really wanna talk about the concept of model-based systems engineering. All right, that's about XPLM. XPLM was founded 10 years ago as a friendly spinoff from Agile and the former Agilent partner team in Karlsruhe. We've got 4 business units, all of them somehow dealing with PLM. Solutions is the part of the company developing integration solutions for a huge variety of PLM and authoring systems. Such as CAD, but not only, we are also having add-ons in our own applications and a portfolio implementation services. That's my colleagues that do the PLM projects and install and customize PLM systems. Operating support means helping customers to administrate their running PLM system and the business unit process consulting, which I'm working in, is the one helping to analyze and improve engineering processes from the classical change release config management to more modern approaches such as systems engineering and model-based systems engineering. We've got a lot of partners. This is just a few of them. Mainly we maintain partnerships with PLM vendors, but also authoring system vendors for mechanical CAD, ECAD, EDA, as well as we are a member of standardization groups such as the Object Management Group, OMG, where I'm working together with many others on the standardization for the Systems Modeling Language 2.0. We have got offices in 3 countries, 4 of them in Germany, one in the US in Wooster, which is close to Boston, and one in Switzerland in Affraticom, which is close to Zurich. Just a short slide I can quickly go over. This is the standardized xPLM integration platform by which we achieve integration scenarios for the different authoring systems for mechanics, EE, and software. We are also integrating with the ERP world and component databases. Which get more and more important. In my field, process consulting, we help our customers to analyze and improve their engineering processes. Here we see classical PLM consulting, mainly change and release, but also other important fields of processes such as variant and CAD data management. There are also consultancy services we offer before PLM projects start. So if you're thinking about introducing PLM or enhancing your PLM installation, we should definitely talk about it at our booth. Besides that, we see here, as I already mentioned, the things we do for requirements management and MBSE. Right now we are engaged in research projects with universities and Fraunhofer, for example, but we also face more and more demand for industry projects. This is why we offer MBSE starter kit workshops to give our customers orientation in what MBSE actually means to them. Okay, this is a quick one. We have done a lot of PLM projects in the last 10 years. If you need someone dealing with installation, customization, and support, your IT with administration of PLM, we are the ones to talk to. It depends a little bit on which PLM system you've got, but I guess we can figure something out. Last but not least, this is one of our applications. We're also developing PLM add-ons for technical documentation. That means the product data stored within PLM can be used to better describe your products and to make the technical documentation process faster. This is available for both of the Oracle Agile Systems, EDM as well as Agile PLM. So much to the commercial part. At this point, I would like to hand over to Mr. Sven Igner and EGO.

Okay. So, thank you. So, good morning, ladies and gentlemen, and a warm welcome from my side. My name is Sven Egner, and I'm an engineer at EGO, EGO Products, since 2006. So in my business function, I'm a process manager in the division of innovation, research, and development. So in my function, I'm responsible for the IT tool integration to our processes. One big tool in our IT landscape is the Oracle Agile EPM platform, and our partner XPLM is supporting us here over years now. So before I start with some detailed information about Agile, who is EGO? EGO is a semi-sized company in the southwest of Germany. And we are developing a lot of components and system solutions for household appliance manufacturers. One of our biggest customers, for example, is BSH, Electrolux, or Whirlpool. So the company is founded more than 80 years ago from Carl Fischer. He was the guy who developed the first serious electrical hotplate. I believe everybody of you knows them from your kitchen, this old cast iron gray hotplate. So this is where we come from. Today, EGO, it's a bigger company around the world. We have 18 distributions and 60— 18 distribution, sorry, and production sites around the world. In 16 countries. So in this size, we have 6 development divisions around the world, and we are developing induction, touch controls, controls for washing machines, refrigerators. It means it's a huge field, a huge product portfolio for our customers, and everyone has different requirements we have to be fit for. So in 2013, these are the older values, we have a turnover around €540 million with 6,000 employees. So this is EGO. The headquarters is here in Germany, close to Karlsruhe. So that you get a feeling what we are doing. Here you see a product from our Japanese customer. This is a dual burner, gas burner hob with a touch, twist, and Wi-Fi control module inside. What does it mean? You see here on the, on the picture, the customer has developed his own app to control the gas burner power and a clock timer. But all these features are coupling with our controls. On the other picture, you see this finger is moving on a twist hop. This is a magnetic hop that is placed on the top, on the surface of the ceramic. And you can move it. You can twist it. And you have the control of the power with this twist knob. By side, you see this illuminated We call it SmartKeys. SmartKeys, this is not a typo. This is configurable illuminated interface. It means each symbol you see here can be customized by our customers. They send us a symbol. In the manufacturing, we are producing this symbol on this SmartKey. And then you can illuminate it. With the PCB in the background, and it's touchable. You can use it as a touch control. So on the right side, you see the picture of the PCB itself. In the middle, this is only a single Smart Key as a power on, power off switch. This is the switch you normally know at the knob at the front of your cooking zone to switch on or off. So, but this is touchable, and if you have activated your hop, you can use the twist controls. And on this picture you see two twist control modules with the smart keys on it. This is the solution we developed for our Japanese customer, and this is out in the market in Japan now at the moment. So The next slide is an overview about, we heard something about vision, a PLM vision, a PLM strategy. PLM is not a tool itself. So ETO is dealing over years now with to find an effective solution to implement a PLM. So at the beginning, we start with a document management system in the beginning of the '80s. With CADIM. I believe Mr. Aigner will remember this time. Over the years, we are growing and the tools are growing with us, or the market supports us with more powerful tools. EGO decides to use the Oracle Agile EPM solution as a base layer platform to come on to a PLM strategy. So you see the different locations as example, the different authoring systems. We have 6 development divisions around the world, and they are working with SolidWorks, our old ME10 system we have running too because we have an old history. We have ECAD in-house, the normal office integration for technical documentation with Word, Excel, and so on. And all these authoring systems are integrated in our Agile platform. Another big point is we have integration between SAP and Agile. We are shifting data between them. So, and with this platform now, we have the possibility, and this was started in 2003, we implement our paper-based change workflow, change process into Agile as a workflow. Each, you know, is using Agile for product change management with a standardized workflow, with approval processes, release processes, and all documentation you have around it. The next level is the product data management. With the capability of Agile around the world, we have the possibility to replicate our technical documentation to our manufacturing sites. They know all the time they have a released version of this document in the manufacturing site. So, and last year, or yeah, it's a little bit more than last year, 2.5 years, we start to implement our project data management into Agile. It means at the moment we have running our All our project data, all relevant documents for risk management and legal stuff is collected in the project, in the data object in Agile. So we have a lifecycle on this project with all our milestones. And this is the monitor for us, the master for project at EGO is Agile, because here we have the results of the project, we have the documentation, And we have it under control at the milestone approval. We check via agile if we fulfill all requirements. So, and the next level or the next task for us is to become a requirements management. Because we heard today the requirements of the customer are changing more and more quickly in the time, so, and you have to follow. And each year as a component and system developer and supplier, we are on the focus of our customers, and if they change, we have to follow quickly. We have it under control. So the head of innovation research and development decide in 2013 to start in our main development process with the WE model you see here. And the V-model starts for EGO with the customer requirement specification. This is the paper we get from our customers. And then we translate it into our internal product specification and we add additional requirements to fulfill all standards or whatever you have in a project like that. So, but then you see the solution from the Japanese market. This is a system solution. Means you have to look in the environmental of this product, how you can implement the system, what requirements you have on the unit, what requirements you have on the module. So, but this is only requirements management. Later on, you have to verify or to validate your results on the module level, on the unit level, on the system level with the integration tests. So then you have the internal verification of your solution, and at the end, our quality management doing the validation to check if the solution fits with the customer requirements management. So this was a decision from the head, and so we are looking for a solution, an IT tool that supports us. If you look around in the market, different requirements management systems, but these are often standalone solutions and are not fully integrated in our processes. And this was the reason for EGO, if you heard about Agile requirements management, to start a pilot project, how we can use the requirement management in Oracle Agile EDM to be on one platform with our product data, project data, and so on. And in this case, Michael Pfennig and his team, the colleagues of xPLM, supporting us now for more than one year to become a running requirements management in this platform and to see how we can go on for the future. But in this case now, Mr. Pfennig will give you an overview what they have implemented and where we are at the moment.

Alright, thank you very much, Mr. Egner. Let's come to the case study. To get started, I want to show a quite old model, the Y-CIM model. CIM stands for Computer Integrated Manufacturing. And even if it's quite old and most of the ideas that were part of it never really found their way to reality, it is nice to look at it as it is identifying the major process chains of industrial companies. On the one hand, there is the supply chain, which is the ERP world. This is where the production is managed, the sourcing is organized, and so on. And there is the engineering chain where the real product innovation is happening and the technical definition of the product is done. The main difference from an IT point of view is within the quality of how those chains are supported in the real world. Where most of the ERP systems are able to manage the actual data alongside the whole chain from production program planning to target performance comparison, the engineering chain lacks of such strong integrated data handling. The real world does look a little bit more like this. The early phase of engineering chain, or let's call it an innovation process, hasn't got any or less efficient IT support. You will recognize that there are a lot of fragmented models, inconsistency because of isolated so-called island solutions and not a single system that is managing the data. Besides PLM, there's probably ALM, SLM, SEM, network drives, SharePoint, email, and so on. In other words, if we wanna improve the way we develop products, we need to focus on the early phase. There is the strong need to better describe the product as a whole instead of describing it with fragmented discipline-specific models that are not interoperable. Or you can say it differently. If we compare the two worlds, production on the one side and product development on the other, what is the level of tool support we can expect here? In the early phase of production, there are by now 3D printers getting more and more common. The technology is so sophisticated, in a few years we're able to print human organs out of stem cells. On the other side, what is the level of tool support we can expect for the early phase of product development? It's probably Excel, or a little bit better, isolated requirements management tools. Such as IBM Rational Doors. I know the comparison is not quite correct, that's for sure. I just want to be a little bit provocative to make you think, is that really all we got? Or are there better ways to do that? All right, let's see how requirement management is done today. Usually you will have a couple of documents to be reviewed by a couple of people. For example, there is a document describing customer requirements. For the whole product that is to be developed, or you will have a couple of internal requirements documents. You need to specify tests to be done with prototypes physically or simulation models virtually. As I said, the most common tools to support this are probably Word or Excel. The problem with such document-based approaches are they becoming very large, the documents, and especially when the product is complex and you are not just selling screws. By the way, to tell a short story, one or two years ago I talked to an engineer who is working for a company that is building submarines. There are not too many companies in Europe building submarines, so probably you know who I'm talking of. They usually interfere a lot with defense departments and have to deal with a lot of bureaucracy. What they did in the two or more years necessary to write a specification is they wanted to test is actually anyone at the customer side is reading the couple of thousand pages. So what they did is somewhere on a page quite in the middle of the document, they wrote a sentence, whoever calls the number 0049 something something something, we eat a pizza and a free bottle of beer. No one ever called. So you see a document-based approach can get pointless if the product you want to describe is in detail too complex. Better is an approach called structured information. Instead of using documents as containers for a lot of information, it is probably better to being able to address the single information items directly. And the idea is even to link them together so you know, for example, what requirement led to which design decision in the overall development of the product, or even more important, which test satisfies which requirement and which parts in the BOM do I need for that test. Yeah, that's probably the way it should look like. To get such an approach working, this is definitely something involved with much training. Engineering needs to learn how to formulate requirements to unambiguously describe what a system should look like or should do. For example, if you're writing down requirements, they need to be, as I said, unambiguous, unique, they need to be testable, and so on. Also, you need to have certain attributes or metadata, if you will. So you can start to trace. In other words, requirements are more than a sentence. So you need version control, priority, you need to know who has been the author and so on. Additionally, managing requirements shouldn't create too much administrative overhead. So you need to find a compromise here. Also, you may need open standards to exchange requirements with suppliers or with customers. The ReqIF requirement interchange format by the OMG is something to look at when you start to set up requirements projects. The ReqIF standard has been especially designed to help exchanging requirements with external partners. It has been driven by automotive and is purely XML-based. You see that ReqIF defines certain attributes requirements must have. That's called information types. And moreover, there's also the chance to extend those requirements, uh, the attributes by two specific metadata if needed. If you are a DOORS user, it may be interesting to know that RegIF 1.1 is supported starting from release 9.4 in DOORS. And if you're interested in the Systems Modeling Language, SysML, most of the available tools also support a RegIF standard. So what does that all have to do with PLM? Remember the V-model Mr. Egner had in his presentation in systems engineering? This is the process model that is being used in systems engineering. People don't think too much about agile development methods such as Scrum. PLM is a management system, not just for the development of the product. You will probably manage your product over the whole life cycle, but with a strong focus on the development of the product. The most easy view on this V is you probably have requirements in the beginning on the upper left, and you will have the BOM and the reference CAD data On the bottom, it says items here. And on the upper right, you will have the tests. So when I'm looking into the industry, what is my impression? If there are tools for requirements management, then they support the management of the requirement and also the link to test and verification methods. What is usually missing is the link to the product information within the PLM system. So you can say those systems are operating on different levels and lack on integration. That means product data you will definitely need for testing, which are the parts to be tested, does not automatically come from your PLM system, but are put into the requirements management tool manually. So this being said, what did we do at the EGO project? We are focusing on the test case management with Oracle Agile EPM. This is because the requirements management at EGO tends to be driven by testers. And it seems we are able to better improve the whole concept when there is a rapid benefit for the users. So at testing side, we'll have defined require— verification methods tracked by the PLM system. For example, that means you are able to assign a certain status to test, like test has been successful or test failed. Come to that later on again. Then you are label— then you are able to link those tests to the requirements and say some tests are verifying the requirements and others are validating them. The difference between validate and verify is something you can talk about it at our stand. I don't want to get too much into detail here. Instead, let's have a look at how it's done in the PLM system. In Agile EDM, you will have or you will find certain entities setting up the requirement structure. There is the base requirement, which is the root. Then you got structure requirements. These are the NOTs and you will find text requirements which are keeping the textual definition and the necessary set of metadata. On the left there are several defining methods for testing. These are tests that are usually used at EGO. What do we have here for example? Oh, I don't see it here. For example, dimension tests or voltage dip test. Then you are on the right, you see the mask for the base requirement. That as I said is the root every other requirement that the project is referring to. And you see here the linked text requirements, which are the leaves of the overall requirement tree. Next slide. Here you can see for example one text requirement and its relationships to test cases. Test cases are assigned a certain ID and you can see if they are to validate or to verify this text requirement, the text requirement itself, has got a status which is in work. So probably there are still people working on it and it has not yet been released. Then you are also able, when you open up the project base requirement, you can see the whole structure from requirements to test cases and also to items and the BOM. Also we are able, but I think this didn't work in the project, to generate a report of the defined test cases. ETO calls that control plan. What we did in the EGO project is all PLM-based implementation, which has been fine so far for EGO. In other companies, there will be probably requirements management tools such as DOORS in place. Then a better setting would be to integrate PLM with DOORS so you can access the product information from DOORS and all the other, the requirement and test case information in DOORS via the PLM system. They need to be defined, a leading system for requirements. In this case, it would be Doors. All right, so much to the case study. If you wanna know more about this project, just visit us at our stand. Mr. Egner and myself will be around this coffee break to further discuss details. Model-based systems engineering is probably thousands something you have heard of, but which isn't really implemented in the industry right now. I'd like to start with an example from a survey that was done by Fraunhofer summing up the status of systems engineering in the German industry. One small example I'd like pretty much was how the different engineering disciplines are describing their product. Engineers from the 3 different disciplines were asked to describe the product graphically. They received a pen, a piece of paper, and started to draw. A mechanical engineer started drawing a 2D geometry of one of his parts and said, "This is what I'm working on." The electrical engineer drew a circuit diagram and the software engineer drew a class diagram, probably something in UML of his software. So what does it tell us? Engineers work with different models and most of the time they try to communicate among each other. They don't really understand each other. Other, for example, when a mechanics guy wants to know the overall system, how the overall system behaves, and the software guy is just showing him his source code. So in other words, the problem of interdisciplinary working is not so much because the engineers are not talking to each other, well, sometimes even that, but it is more because they think in different models. Different models, of course, that are describing the system on different levels of abstraction. This diagram tries to show this difference. It does not necessarily have to be RFLP, requirements, functions, logical building blocks, and physical components. It can be something different. The idea is that abstraction is getting higher from the bottom to the top. What I try to explain is that mechanical engineering in practice is fixated on models on the pure physical level. Mechanical engineering means drawings. It means 3D models of geometry and structural information. Defined in the bill of materials. In the EE world, the actual models are more on a logical level. It is not too important how the implementation of PCB— of a PCB is done in terms of its geometry. It's much more important is how the different components of the PCB are interconnected with one another. Schematics play a much bigger role here. And in software, first of all, it would be more of a philosophical question to discuss what a physical level is. In that domain. But besides that, I think the leading level of abstraction in software is even more abstract than the one in EE. You can call it function level, if you will. So what is the problem we try to solve? There's the silo mentality, which is being complained about quite a lot. Not just in the industry, but also at universities. Engineers are raised to refer to themselves as a mechanical or electrical engineer. The huge question in times like this, where products tend to become more and more complex and the dependencies between mechanics, electrics, electronics, and software are getting higher, is, is that still the way to educate students, or should they be more taught interdisciplinary? Or at least, how can we make collaboration between the engineers more efficient and promising? Systems engineering is nothing new. This is the definition of the International Council on Systems Engineering, COSI. It tries to help specify a system in a neutral way. That means I first wanna know what my system actually is going to do before I assign a certain discipline to fulfilling the certain function with their implementation. Systems engineering was first used in the Apollo program. This is why I put a picture of the Saturn V rocket in here. And what is the difference to model-based systems engineering? From a process point of view, there is actually not a big difference. I would even call the processes equal. The ISO standard 15288 is something to look at when it comes to systems engineering. The difference between MBSE and SE lies within the usage of graphical notations. For example, the Systems Modeling Language, SysML, is something to be used or here or even Modelica, even if the focus of that language is more on the simulation of physical models. This is actually the definition of a working group I'm working with. At the German chapter of INCOSE, Gesellschaft für Systems Engineering. It is called PLM for MBSE and deals with the integration scenarios of MBSE and PLM, or more specifically, how should PLM systems look like if MBSE artifacts need to be managed by PLM systems? If you're interested, we are always looking for use case suppliers, so get in touch with me and we can figure something out. Here you see a short example of how SysML looks like, graphical diagrams like in UML. The upper is a block defining, block diagram defining subsystems and the lower one is a requirement diagram. So you see requirements are part of SysML models and therefore requirement management is something also possible to be done with a modeling language. How exactly is left to research right now. On the right side you see a cube which is the actual model. There are relationships between the different diagrams assigned with a certain meaning. So the model itself is quite more complex than it looks like when just looking at the diagram. The user itself can interact with the model in two ways, with a specific diagram or still with a document. Important to say is that documents in a model-based approach are reports created out of the model, but they are not any longer the leading source of information. This is important to note here. So what is the idea behind all that modeling? SysML or other specification models try to be the glue that holds together that fragmented models. The different engineering disciplines are creating those different models. Usually you've got MCAD, EDA, and ECAD, but those models are hardly integrated. Most of the time only for geometrical information via exchange files such as STEP. But first of all, it is the really— but first of all, is that really working everywhere the way it should be? And secondly, There are other things than geometry that need to be shared across disciplines, behavior, for example. What MBSE tries to do is to describe the system on a neutral level and fill the gap in the early phase. It wants to deliver computer-operatable specification models instead of documents only to be understood by the engineer in front of the screen. By the way, when I first showed this picture, I got the answer, shall we all go into the cloud now? I'm open for better diagrams if anyone has a solution for that. Here's a quick overview on not necessarily complete list of models that are actually in a model-based approach in product development. Specification models, as I said, probably SysML, UML. Then you've got simulation models. This is something to be done with Modelica or MATLAB. And you see here the common specific discipline-specific specific models such as MCAD, ECAD, EDA, and the software code. Key question is, if we really want to bring a model-based approach to reality, we need to figure out how to manage all that models. They need to be managed not just for collaboration between engineers, but moreover for version control and a well-balanced config management. Here you see an extended v-model derived from what Professor Eichner is working on in Kaiserslautern. And what we wanna do is we wanna use the PLM system to manage all of the models and not just the discipline-specific ones. So in the end, what is the big picture? Back then, many years ago, we started with drawing boards and we're managing the drawings and archives. The metadata was probably the drawing number and there were maybe some index cards helping to organize the drawing. All done manually without any usage of any computer. Then someone had the clever idea to introduce 2D CAD. I know, I don't know if any of you is still working with that. Well, I heard you are, you're still using ME10, for example. But generally the introduction of 2D CAD was not so much a big change. It was just changing the authoring system. Instead of a drawing board, the new tool was then the computer. The drawing were printed out and managed physically in the archive still. Since the introduction of 3D CAD, there came the necessity to manage the models virtually, and PDM or PLM systems were introduced. And what we are experiencing now is the introduction of more authoring tools. And the question is here, how should PLM systems need to change in order to manage specification as well as simulation models? This is referred to be the fourth step of product development. Some may call that a vision, maybe. For me, that's just a too strong word. I do more like to refer to a former German chancellor who once said, "If you have visions, you should see a doctor." For me, this is not really a vision, but more just the next logical step. No one really knows how exactly that step will look like, but this makes it so interesting. This is definitely a topic to discuss, and I'm looking forward to hear your thoughts on that. Thanks very much for your attention.