Product Line Engineering for Aerospace & Defense

00:03 Presenters, the virtual floor is yours. Thank you, Andy. Thank you, everybody. And, I assume that, those that are here have interest in product line engineering, and the webinar today will not go into the full details of what product line engineering is, but, will highlight the experiences of, Lockheed Martin, Safran Seats, and, PTC.

00:33 However, we will still give a quick and brief introduction. If you are eager to know more about it, INCOSE has, as Andy, reminded, a PLE working group that I lead together with Roland Darwin, and, I will be happy to, have you there journey it. So let's start with the definition of product line engineering. So Or to say it better, when engineering is considered to be product line engineering. Since today we will cover mainly two, industrial domains, that is the aerospace and

01:09 defense and aviation, we can consider to summarize it really to, to, in a nutshell, product line engineering if organization manage a family of systems and missions configuration as a one digital engineering ecosystem. So connected by a digital thread, those assets represent the hundred and fifty percent in order to maximize reuse while maintaining strict control of

01:41 mission-specific variation, while maintaining control of the variation that you want to offer as added value to the customers in the final products that you derived from the product line. Now, what does it mean? So in, If we follow the standard, that's the main, source, shared source of information, official source of information that's tool agnostic, of, feature-based product line engineering, that the two six five eight zero from twenty

02:15 twenty-one, we can see that, everything start with what you would like to reuse, so the asset that you would like to reuse. If we take here a simple radar example, how do you de- how do you reuse or you basically reuse your development assets? You share your development assets. So you need to build what is called a hundred and fifty percent, that if you are from PLM domain, probably be familiar with, but also if you are now from system engineering domain, has become quite, a common terminology.

02:45 And this hundred and fifty percent may include both ALM, application lifecycle management assets, and product lifecycle management assets, like requirement, test cases, architecture model, source code, and the bill of material. Now, the main challenge with reusing hundred and fifty percent or with the so-called library approach is that you need the rules, you need the communitories, you need the, a way to reuse. You need to know what to reuse and how to reuse. So it means that you will have to establish what we see on the, on the, what we call

03:19 feature catalog. The feature ca-catalog is basically your single source of truth or validity. If you're taking a simple example, what we are gonna do when we define a feature catalog or feature model, we define the option and the alternatives that, we would like to select, and we link, we map, we restrict to those option and alternatives their related engineering assets. So in this case, we can have a, a radar with a frequency band, a S-band, X-band, and dual

03:49 band, and we link the related requirement, the related architecture block and parts to the specific options. There will be, of course, one part that will be common, that will be carry over. The part of those assets that you are not, going to vary across your products. And, after we do that, we select what we call the bill of feature. We configure the bill of features for the variant that we, want to realize. And thanks to the PLE engine, product line engineering engine, we are able to create the

04:24 variant described by the related one hundred percent assets. So we can have, in this case, different type of radars, so vehicle radars or, MARIT radar. So that's a very brief introduction of what product line engineering is and, I will now, hand over to Luca so that Luca can give the Safran seat point of view. Before that, I want to highlight that Safran and Lockheed Martin are a different stage,

04:55 stages of adoption of product line engineering. So Safran is, in the definition phase and, just started the journey, while Lockheed Martin has already several years of experience in the adoption of the, of product line engineering. Thank you, Luca. Please, you- Thank you, Marco. The stage is yours. Thank you, Marco. Good morning, everyone. The next slide, please. We, what we have here, we introduce why product line engineering is interesting for

05:26 the interior markets. Safran Seat is a company producing seat for the aircraft and, helicopters. And therefore, if we just looking at the We have some information here. Typically, the first one, it is linked to the delivery aircraft by Airbus. We are, We can see that we, we are in a ramp-up phase. Okay? And we are close to eight hundred last year, and we, we are, The target for twenty twenty-six will be more than eight hundred and

05:56 fift- seventy, aircraft delivery by Airbus. We see as well that we have A lot of new, trip or new potential flight, direct flight from point A to B with a lot of flight hours, therefore different needs is coming. Okay? And the number of passengers are growing as well. Okay? Therefore each year we have more passengers than the year before. If we now ana-take the analysis of how many

06:29 what it mean for our seat manufacturers that we-- the number of aircraft delivery will strongly increase, is that, if we look in the-- through next decades, okay, we will have, more and more seat to delivery. Okay? For the interiors market, we have two type of product. We have the line fit, that is the seat that will be mounted for the first times in the aircraft, which is brand new. And after we have the retrofit, when the airlines decide to, improve,

07:00 update their interiors. Therefore, we-- what we saw that we have clearly four do- around four millions of new seat planned for the next decades for the line fit seat and more than five millions for the retrofit seats. Okay? Can you please push on the button, Marco? What it's meant that we have roughly nine dot one million of new seat in the next decades. We make the same studies last year. In the last year, the study, it meant that to-- it was from public sources seat, around

07:35 eight dot five millions. Therefore, we see that in just in one years, the, the estimation, provided by press and newspaper, you, you, you can-- what you can easily find, we have an increasing of nine percent of, of marketplace. Okay? And each new aircraft, clearly, they would like to integrate new technology, new interior, new designs, and clearly make a difference for com- for airlines A to airlines B. Okay? Please, Marco, we can go to the next slide.

08:08 Okay. What it mean that we, we-- this, this number of product different customer needs, it, it means that, we have-- we should provide for each company something totally new, a totally difference. Therefore, we need-- we saw that we have some airlines would like to have a rim-blown seat, what is st-st-- a seat, a seat that are not in forward position. Some companies would like to have more, bigger business class seat.

08:38 Some companies would like to have first class seats. And if you take just the, the, the pictures on the bottom line, the, the, the center and, and the right one, what we can easily identify is that also if companies purchase a quite similar seat, they want to have a specific customization. Okay? Therefore, what we can see, it is our challenge. We produce business class seat as well as economy seat, and we have to, to think about a

09:08 different product line strategy for economy seat on which we could potentially be more on, customized to order products from business class seat, or clearly we need to bo-- be oriented our product line strategy more on, engineering to order seats, because the customization level is more important. It is a, a, clearly a, a market differentiation between a seat A and seat B. Okay? Marco, please can you go to the next one?

09:40 Therefore, we have introduced in the next slide the fact that airlines would like-- each customers would like to have a different seat, different function, different colors, different, different, passenger experience. On the other point of view, we have a second degree of variability that is linked to the aircraft itself. Okay? I don't know if you are familiar with aircraft interior. The seats are mounted on the rails, and each aircraft is a dif-- we have different wider of the s- of the aircraft. We have different dimension.

10:10 The body is not the same. We, we have different fittings, different interface, and we have as well to, to compliant with the decompression rules, with, aisle dimensions, with galleys, monuments. All the other facilities that are installed in the aircraft, they can dif-- change from aircraft A to aircraft B. And we have to put, put the seat in front of all the power grid, position and as well of oxygen mask, position.

10:44 Therefore, what it mean it will adding to the customer, variability, we have as well integration variability linked to the, to the aircraft and to the airframers', environments. Okay. Please, Marco, can you go to the next one? And therefore, clearly would say therefore, why clearly it is-- we think it is important for us, okay, that if we repeat, the design, it will be inefficiently and potentially we, we increase the cost of our products and

11:19 therefore supply chain and all the, the, all the enterprise, cost elements in this, in this way. And we, we, we have to as well to want to shift from function-centric to modularity, be able to reuse some, capabilities, some system functions, some modules, and be able to install to, to, to all the seat that we propose or, or part of the seat for some specific customers. And as well, the-- if we are able to create, some part with potentially, as a standard

11:54 core of the seat, we can propose to the customers more differentiation, differis- differentiation, value on specific models that they would like to, to have because they think it is a very added value for them to have a different solution, for example, for a console or for a, or I don't know, for a APCU or for some interface. Okay? We want as well to propose fixing. We have, I think most of you to propose a customiz-um, customization and reusability.

12:24 And product line is not just engineering issues, is industrialization as well. If we are able to standardize parts, it will be as well easy for industrialization manufacturing team to have less part number to manage, to pro-pro-- to be reduced potentially some logistic issues and to produce more quickly. Okay? And clearly, what we think that if we have to, to be a successful product line th- journey, we need to align the company on the same RC

12:59 and the n- same KPI. For example, we have the-- we follow the NRC or the RC, but we should align on the same KPI to follow the performance from the point A, from the design office to the delivery sy-sy-service. Okay? And clearly, we know that we have to make around three, customers to have a good product line. What we want as well to light u- light on that for our mar-market, we have some bespoke, and a product line cannot fulfill, all the markets.

13:29 Therefore, when we build a product line, we know that we have potentially to reduce some A product cannot be offered to each airlines, can be offered some, some customers and therefore for other ones, we have to produce, propose another product line or a product, a totally different product, not derived from product line. Please, Marco, go, And therefore No. Okay, can you please stay on the previous one? And therefore clearly, what we want would mean that we cannot have a o-one size fits all

14:03 product line and universal product line. We have to adjust the concept about the product, the customers and the markets. Okay? So for one size fits all solution th-- will not fit in our case. Please go to the next, one. Therefore, when we say this, definitely to the MB/PD approach and the PD approach should be managed across all the function, therefore from the ALM to the PLM to the ERP. Okay? And we are start to think how we can, share

14:33 the data. Okay, which data we manage with With which system we manage which data. Therefore, we found for the ALM and the BSC, we manage requirement function, for example. We have the EBOM and the MBOM will be in the PLM and all it is linked to work instruction and supply chain will manage the PD, for, by the ERP. Typically, if we have a, a placards to say made in the US or made in Europe, okay, potentially we have not to manage in the PLM, we could manage directly in the ERP, closely

15:03 to the assembling line. And, clear- what you see, also if this, Marco will present later on, some, some example of, digital threads. We are working to have digital threads across different tools from different tool vendors. Okay? And therefore to be successful from this, we have to, to be able to connect all these tools to be most efficient i-in, in our journey. Please, Marco, go to the next. Okay, and also if you are in a flow down approach, clearly what we know is that, a lot

15:37 of We have a PLM and the ERP with several information according to our legacy sy-system. And therefore we have to link not only in the, in a flow down approach but also in bottom up approach to be able to connect the relevant information that typically the costs were managed mostly in the ERP. Potentially, we have to link the cost information to the ALM to be able to retrieve in the ALM. Okay? Therefore, we have to mix to find a good compromise between bottom down and top down approach in digital threads. Please, Marco, go to the next one.

16:08 Okay. Clearly, what we work with, this will be the next presentation. It is Marco, will introduce how we, we work to connect ALM and the PLM. Okay? What we know as well, and that in the, in COSE, in COSE framework, we COSE framework, we would like to extend the PLE, knowledge because today it is something that is, not implemented yet.

16:38 And we, we know that we cannot go in the customize of the, of the all the approach because we are not exactly like the automotive industry, and we have potentially to adapt our methodology. Okay? And therefore, clearly, what we are, looking through the inCOSE work is to work on how we create a product line, for engineering to order best practice. This is something that we think we have to develop with the community to go forward.

17:08 Co-, can you go to the next one? Thank you for your attention. And Avril, the, the I give you the handle. Thanks, Luca. So I want to thank inCOSE for the opportunity to be here today. And just a quick note before I jump in, the views and opinions I'm sharing today are my own, and they don't necessarily reflect the views, positions or policies of Lockheed. Next chart for me, Marco. All right, so let me bring this into the Lockheed Martin context and start with the environment we're trying to change.

17:39 Lockheed Martin is a very large and very diverse engineering enterprise. We've got four major business areas: aeronautics, missiles and fire control, rotary and mission systems, and space. And within those businesses, we're dealing with everything from tactical aircraft and helicopters to missile defense, precision fires, radar, command and control, and spacecraft and strategic systems. So clearly, these are not all the same products.

18:11 They don't have the same customers. They don't have the same missions. And they don't necessarily have the same acquisition or certification environments. But there is a common engineering challenge that cuts across many of the businesses. We're being asked to do more, we're being asked to move faster, we're being asked to increase production, and we're being asked to do that while maintaining the technical rigor, quality, cybersecurity, and mission assurance that are absolutely essential in our industry.

18:44 And one of the important shifts we're seeing is that we're increasingly thinking beyond just individual platforms towards the mission that the platform participates in. And that's really the premise behind, you know, mission engineering as its principle, is understanding the broader mission, the capabilities required to accomplish it, and how multiple systems and technologies have to work together to deliver that outcome. And that matters here because the customer doesn't ultimately buy a requirement set or a document from us or an individual subsystem.

19:15 They're buying a mission capability, and that's our interesting engineering challenge. Because the missions stay relatively constant and all the platforms and technologies and threats and the individual system configurations keep evolving, we're seeing a lot of tangible examples of pressure coming to meet their needs today. Lockheed has publicly described increasing its PAC-3 missile production in response to growing demand, as well as capacity for HIMARS, JASSM, and LRASM.

19:50 And the company is, you know, also out there on public record talking about some of our F-35 deliveries and how we're trying to move those left and help the customer. So when we're ta- when we talk about transforming engineering, it's not an abstract exercise for us. The customer is increasingly saying, "I need more capability. I need it sooner. I need you to be able to scale, and you still need to be able to accommodate my particular mission." And that's a really tricky combination. So because of our response to all of these new customers needs to, to create another largely

20:23 independent engineering effort, like, we, we can't do that, right? So this increased demand quickly translates to a need for us to get our cost and schedule under control and manage this in a bigger picture, and that's what brings us to product line engineering as a solution space. So next chart for me. That's just the context, right? So Lockheed's big. How do we change our approach? Our question becomes, how can we respond to all these demands without simply adding

20:54 another layer of engineering effort every time? Today a lot of our engineering naturally happens at a program level. Our customer approaches us, they have a mission. We a- agree on a program, you know, assuming we're awarded. That team develops requirements and architecture and designs a system, and they test it and they deliver it, and that makes perfect sense from the perspective of an individual program. But when we step back and we look across our enterprise, we see something

21:24 else is happening, right? The next program comes along. It has new requirements. It has some different interfaces. It has a different customer. It might have a d- have a different mission, but a lot of the engineering assets aren't necessarily something we have to start from scratch. So typically we take what we learned on a previous program and we reuse some of it. But often that happens through people or through documents or models or sometimes just whole other, you know, designs for hardware.

21:54 So we might take that previous solution, modify it, and essentially create another one for that program that they own. And sometimes in our documentation and our socialization of this PLE concept, we call that clone and own. But that's the problem that's represented here. There's nothing inherently wrong with it or reusing a previous solution. The, the problem's what happens over time. We end up with multiple versions of essentially the same engineering knowledge, right? Then the versions diverge.

22:25 A couple changes get made here or there. We, we want to factor in lessons learned from another program that's relevant. The requirements deviate a little bit, right? They, they drift in a different program. And then we have to figure out what should be propagated where and what shouldn't be, excuse me, propagated and what version is authoritative, and all of this is expensive. And more importantly, it makes it really hard to move quickly. So that's where it's important for us to broaden, you know, here publicly what, what I

22:56 at least mean by an engineering asset, right? It's not just necessarily a piece of CAD or a CAD model or hardware. You know, it could be a requirement, it could be a functional model, could be a logical architecture, a hardware design, a system, you know, a software component, a firmware baseline, an interface definition, a verification procedure, a test case, or a manufacturing process, right? All of these things matter, and cutting down on recreating them and increasing our reuse of

23:31 them is really important. They're not independent assets, right? They're all connected. A requirement ends up driving a function. A function drives an architecture. Your architecture is gonna get allocated, you know, but allocate its behaviors to hardware and software and, and firmware. And all of those elements also have interfaces. So when you start factoring in the verification of that and the test assets and all of those ways that we demonstrate that the system actually performs as it was intended,

24:03 we've got a lot of connected material, and if we're gonna get real leverage from reuse in our context, we don't just wanna reuse one piece of all of those, right? We wanna understand the relationships across all those pieces, and that's where PLE becomes much more powerful than just having a library of previous designs. This is also where MOSA provides a useful parallel, right? The whole idea behind MOSA, Modular Open Systems Approaches, is that we don't

24:33 necessarily have to redesign an entire system every time our customer wants to introduce or replace a capability. If we establish the modularity and define our interfaces and our standards and our architectural boundaries so that some of these changes are isolated and they don't propagate through everything else, we can begin to start addressing their concerns faster, right, and delivering capability faster. And that's really similar to what we're trying to do with PLE, right?

25:03 We're asking what should be common? What should we allow to vary? What are the rules around variation? And how do we make those relationships explicit rather than rediscovering them on every program? And if we contrast that with what our customers are asking for, right, we're seeing them push for accelerated fielding and increased production, as I mentioned, and that's not just a manufacturing problem because if we want to dramatically increase production, we have to understand our

25:33 engineering baseline. We have to understand what's common and what can vary in the interfaces, and we have to understand all the configurations, right? As built, as designed, as tested. There, there's a lot going on there. So when we go to make a change, we need to be really confident that we're making it in the right place and that it's propagating to the right products, and that's where PLE is a game changer for us. You know, instead of going in and asking, "What did the last program do?" We're able to start asking, "What do we

26:03 know that should be reusable? What is truly common across this product family? Where do we want to intentionally allow variation to occur? And how do we manage all of that variability in a systematic way?" Our goal is not to eliminate customization, that's, that's pretty unrealistic to do that, right? Our goal is to make customization something that we can configure rather than reinvent, and that's fundamentally different engineering model for us.

26:35 Marco, would you hit the next chart for me? Thanks. So PLE strategy. Yeah, you might just wanna build it out while I'm talking, but, all of that information leads us to a strategy for how we're gonna approach PLE, and it's, it's important to emphasize that we're not talking about a giant enterprise transformation where we, like, walk in and we flip a switch and suddenly everything's a product line. At least at Lockheed, right, we've, we've got to phase this. So it starts with the, the strategic vision.

27:06 We need our leadership in a lot of different areas and functional domains behind an approach like this. And we need them to align behind the why and how it connects to the broader engineering transformation efforts that we have underway. So things like model-based systems engineering, concurrent engineering, digital engineering, and a, a big push for digital threads, right? And even now it's getting more connected with model-based acquisition because if we're moving from a document-centric engineering approach towards a model-based engineering

27:41 environment, which we all are, right? It makes sense that we start asking if that same digital representation can continue beyond engineering, right, and support acquisition decisions as well. So PLE isn't really a separate transformation sitting off to the side of all of these things. It, it's becoming one of the mechanisms that give the model-based environment something meaningful to manage. So that could be a product family, right? The common assets, the variability, the configurations themselves, all the

28:13 relationships between these things. And then we've got to make it real here, right? We need the infrastructure, we need the processes, we need the governance, we need really clear roles and responsibilities when you're at a company this big that does so many things. And most importantly, we have to identify what, where PLE actually makes sense. Not everything here that we have going on is a product line, and that's an important point, right? I know it's a PLE webinar, but it's, it's an important thing to distinguish.

28:44 You have to make a decision there. If there isn't s- sufficient commonality for us or if the variations are so unconstrained that we're effectively creating a, a unique product every time anyway, the PLE economics don't really work out for us. So we also have to do that domain analysis, right? We, we look for areas where there is meaningful commonality. We look at the market and the customer opportunities. We end up defining the product line scope, and then we have to establish our value prop.

29:16 You know, what are we really trying to make better? Is that the engineering labor itself? Is it how fast we can turn a proposal out? Is it the time for, you know, establishing configurations or assessing a change, or even just production scale, right? Is Do we evaluate based on the ability to, to in- introduce new variants? Like, is that what we're trying to optimize for? Or it could be something as, as forward-thinking as our ability to maintain

29:50 the systems once they're in the field. Realistically, determining product lines always comes down to some combination of those types of things. It's not black and white. But once we have those, we start testing them out with what we call first movers in number five, right? We, we don't have to prove PLE everywhere at once. We need representative use cases where we can demonstrate measurable value, and once it's proven, then we scale. I'm just checking the time, so I'm gonna try to speed up a little bit.

30:24 Oh, we also have to assess the mission space. Yeah, go That's fine. I'll just jump ahead. Um- So once we figure out all these things, which is tricky, right? We have to turn all of that complexity into something good because it is. So this is, this is where we're at right now, right? The complexity isn't our enemy. In our industry, the complexity is inherently in what we've been asked to do because of all the differences in the customers and missions. And the question becomes whether we can use these tools to deliberately manage that

30:55 complexity or if not, like the complexity is gonna manage us. So this is where all of those really big ideas that are underway, mission engineering, MOSA, model-based acquisition, and PLE really start converging, and they're highly complementary. So I think of it like PLE is giving us the mechanism for turning all of our variability into something that we can control. And at one end, we have all that commonality and the standards in the, in the graphic there, and at the other, we've got custom-built specific configurations.

31:28 And the product line approach to this space is in the middle, right? It gives us a way to say what's common and optional and what's mutually exclusive and the rules behind how we're gonna build things and if the assets are something we should reuse regardless, of the configuration we're building or not. So we're, we're really not just saying, "Here's to a new program. Here's something another program built. Maybe you can use it," right? We end up going to them and saying, "Here are the reusable engineering

31:58 knowledge that you need. Here's how the things vary. Here's the rules for how you should govern all that variability, and here's how to go about deriving a particular product from the product line." And that's where we start to see a lot of benefit. And we have some historical examples to illustrate the value too that I'll skip over in the interest of my, you know, my time, my time crunch. So at the end, this becomes really important for our customers. They're not asking us to go build a better

32:28 product library, right? They're asking us to deliver mission capability. They want it faster, they needed it at greater scale, and that's how PLE helps us. You know, it's not just reuse, it's our ability to absorb change faster. And that's why I, I personally think it's really relevant to where aerospace and defense is headed. Because if we're gonna keep up with all these complex systems, which we know aren't going away, we've got to find a way to systematically capture what we know, so we can deliver the, the diverse and high-performing

32:59 systems that our customers need. So I see that as the promise of PLE. Over to you, Marco. Thank you, April. Thank you, Luca. So they illustrated, very well, the division, the challenges, and the benefits and, of course, why they decided to move to this approach. And one thing that came out from both presentation is the importance of treating PLE, not just, being focused on the reuse of a single asset, but of the entire digital thread,

33:34 on the entire thread of your, engineering lifecycle assets. So as PTC, I would like, I would like now to give you our point of view and what we see with working with customer like Zafran says, Lockheed Martin and many other customer also from other industry. So these are more the pitfalls that we usually hear from customer. First, customers say, "We tried reuse, but..." Okay? So we tried reuse, but first, there are, like customer that start reuse on the MBSE and

34:07 system modeling by introducing libraries, reuse patterns. But the problem is that, most of the time, this type of reuse, is focused on single development and clone and own. So it means that, we use models that can be, that describe a single system and, they remain, like they are very optimized and they are, they are good models in many cases, but they just focus on the, the single the, the system of,

34:42 the single system of, as SOI, system of interest. So this is one of the problem because, like we are basically, we remain, we try to introduce this pattern. It's not just for MBSE. You have the same like in requirement management, you have, you have the same in, other discipline, like source code management. So the reuse is done many cases by clone and own, so copy and, replace, copy and change.

35:12 Now, that's one of the problem. The second one that we see is that usually company that try to reuse think of reusing components of the shelves, com- reusing the specific parts and the harder part and bill of material. That's what also, Hadley, sorry, April and, Luca, highlighted. So it's basically, organization, try to reuse, assets that are downstream assets while the reuse needs to be brought more upstream.

35:43 So we need to design for reuse. And to design for reuse, we need to start from the requirements, from the test cases, from the, those assets that are more upstream. Because also reuse that is just delegated to the bill of material, it will basically be very, very hard due to IP constraint, export control, and specificity that belong to the specific product. Then there is another issue that we see, is that we have like, reuse can happen, of course, but usually it's,

36:14 confined within a specific domain. So it could be an example is the MBSE silo. So we try to have everything within the, the system modeling tool and, to add models, requirement, code generation And, and of course we can establish library within it, as I mentioned before, but then the reuse would be just, will remain internally within your engineering silo. In this case, would be your MBSE silo. It could be your requirement management silo. It could be your PLM silo.

36:45 So we need to establish reuse across silos. We need to break those silos, those silos and reuse the digital thread. That's what I would like to, to show today with the, with the help of an example, that we are working together with Safran Seats. So I will now show a short video that, highlight the focus of, our, example. Basically here we see, so business class seats as, Luca presented before.

37:16 And you can see that there is a, a level of customization, within the, the seats, and depending on the air- airlines that you, you take, so you can see that, the, the, the, the branding is really, like, unique and I, I flow with I flew with Emirates, two days ago, and of course different than Delta and different than Lufthansa. And, this is basically like, the, the power of customization, right? So what, what it means basically, it means that you have What I mentioned before is that

37:50 we need to bring reuse upstream, and reuse can start already with the prototyping, right? So with the prototyping, with the reuse of digital assets, in this case, reuse of simulation assets. So in this example that you will see that we Has been, developed by Safran Seats, and it's been adapted and elaborated, by us, PTC. So we see that we have a prototype seat, used for simulation, so for testing, so hardware in the loop. And, here we are gonna look at three specific variants.

38:20 You have a fully simulated, approach, so it means that it's fully simulated, no hardware pieces are, yet, built. Then you have, like, the physical prototype that the har- how a company were used to do prototyping, and the hybrid prototyping. So that's basically, it's a combination of a simulated part, co-simulated part, and a physical part. And, so let's have a look here with the, this example, and let's, break down, the, the example in three parts.

38:50 First, we are gonna have a look how, we can handle this specific, so the product line engineering, i- within the ALM domain, so application lifecycle management domain. This example I will use, Pure Variant, that the best-in-class tool for product line engineering, that enable, the product line engineering engine. And, we'll use CodeBeamer, but we could have other application lifecycle management tools, that could connect this specific case with Pure Variant as well.

39:21 So and, let's have a look at the, the example here. So we see here, CodeBeamer. So this is like a requirement database of my, of the seats that I want to simulate. On the right side, you see the feature model, so the variability model. That's a widget, that represent the variability model inside, the ALM tool, in this case CodeBeamer. And you can see that we have different features. Now, if we focus on the system configuration features, we see that we have three types of, alternative: simulated components, suppliers'

39:56 physical components, and hybrid configuration. So basically, we have, three different, type of possibility to run a simulation. Simulation is just part of the Now, what we are gonna do, we are gonna link the hybrid configuration features with the, with a specific requirement. And you can go through other requirements. You can start linking all r- the requirements, binding the features with the specific requirements. After we do that, we select one variant. Our feature configuration in specific cases, the basic validation setup that consists of

40:28 just physical parts without, digital simulation, as you can see from the features selected. So just you have suppliers' physical components. And we run a preview. So we run a preview to see what the selection of those features in Pure Variants drives in CodeBeamer. And now you can see that in the preview, you can see exactly what is part, what will be part of this hundred percent, and what would be excluded by this hundred percent based from the, say, hundred and fifty percent, requirements.

40:58 So, and of course we can, switch to another variant. That would be the advanced, simulation setup. In the advanced simulation setup, we can see that other requirements will be, selected based on the configuration. In this case, you will see that other features are, select. And of course, this is just a preview. We don't want to, establish only a preview. We want also to generate the, hundred percent assets. So what we are gonna do here, we are gonna take the advanced simulation setup,

41:32 configuration, and, we are going to, run a transformation. So run transformation means we are gonna transform our application lifecycle management assets, in this case requirements at different level, from, the hundred and fifty percent into the hundred percent, specification. So now we are gonna run a, a transformation, and we will see that the, So I'll speed up a bit because of time. So after the transformation is done, we can go into, the application lifecycle management.

42:05 So the transformation is running, as you can see, and after transformation is done, we can go to our initial stream. That's basically our, hundred and fifty percent. And from our hundred and fifty percent that was already shown before, we can select the created here advanced simulation setup, the hundred percent, that will only include the hundred percent requirement filtered by the feature configurations. So as you can see here, there are much less requirements because there are only the

42:35 requirements in scope So this was the, ALM part. So of course, the, the journey doesn't conclude with the ALM assets, so it continue. And I have here an example also that, include a third-party tools, in this case, CATIA Magic. And we can see how the same feature model, the same variability information for Because at the end of the day, variability doesn't have boundaries, doesn't know ALM, PLM, MBSE. It's variability. It's the variability that you need to realize within your product. We can see how, how this feature model can

43:06 continue, and of course, in Magic you have established traceability between your requirements and your models, and now you want to control also with the same feature configurations the, MBSE model, system model. In this case, we'll see now the requirement sync inside, CATIA Magic, so the same requirement that you have seen, before. And on the right side, the same widget, the same feature model that you have seen before. Here we have an architecture model and, by looking at our architecture, we are gonna

43:36 restrict, so we're gonna say this specific part is restricted by a feature called, simulation, simulated components. And if you use, like, just physical components or hybrid approach with physical components, you will use the other parts. So we are restricting the feature, mapping the feature with the architecture, and now we run the preview in the same way we did, in CodeBeamer in the ALM assets. For the requirements, we are gonna do exactly the same here for the architecture models.

44:08 So we can run the preview. We see what is in scope, what is not in scope, and when we are happy with the results, with these, let's say, simple validations, we are going So yeah, we switch between bas- basic and advanced, of course. And after we can do that, we can run a transformation again. So we can transform our 150% architecture into the 100, percent model, as you see here, and, the same way we did with the, requirements. But this, the journey doesn't end here.

44:39 So we talk about engineering life cycle. We're talking about, bridging the ALM with the PLM. That's basically what Luca represented, w- what Luca showed, what April mentioned as well. And now we have also to bring the PLM part of it, okay? So in the PLM side, what we want to do, PLM, system like Windchill, but the same for other system, other PLM system, they will usually have variant management built-in capability. So we don't want, always the, the, let's say substitute, replace this variant management

45:10 capabilities, but we want to complement this. We want to ensure that the variability that cascades from, the AL- from pure variants, from the ALM assets is also sync with the variability in PLM so that we don't have to redefine, copy, recreate variability there, but we will have a synced single source of truth, leveraging the existing capability of the PLM, variant management solution. In this case, in Windchill, we have option and variants. So here we can see that we are, we are always in pure variants.

45:43 We have our three different configuration. Now we run a transformation. So we sync the information, the variability from, pure variants into Windchill, from the PLE engine into the PLM. So we are gonna, we are gonna publish now information inside Windchill. So exactly the same variability that you have seen before for the representing the ALM assets and MBSE assets. Now if you open Windchill, we can see now that this variability has been, synced. We have system configuration, and the system configuration include exactly the same feature,

46:16 like simulated components, hybrid configuration, and suppliers' parts. So now this is a rendered, CAD of the, of the simulated seats, as you can see. And what we are doing with the variant management application option and variants within Windchill, we are basically create, expressions. So we are, sort of creating similar restrictions between the, BOMs and the, features that we have published from pure variants into Windchill.

46:46 Here you see we are select. Now this part is constrained by, these features, by the supplier physical component. This other part is constrained by another part. So we are gonna create now the restrictions for linking the features that have been published from pure variant, single source of truth of variability into Windchill with the specific, bill of material. We don't break the silo. We break finally the silos here, so we don't have to, the have the reuse in a specific domain. And once we have done that, so we have created all the restriction, now we can, see how this

47:20 is rendered. We can see our 100% CAD, and, different versions, different variants of it. So one is advanced, basic and advanced simulation, as you can see here. And now we can see first, we can search for the, for the advanced simulation, and, we can see how this is rendered in, Windchill. So you can see now that there are some part that are physical and, sorry, all is all

47:50 simulated here because there's no physical part. And, and then if we go to the other configuration, so the basic configuration, you will see that there are, like, only physical parts. So there are, is more defined, more details because we'll include more physical parts. So to conclude, what we are gonna do here, we would like to, explain that we have, like, a end-to-e- hand-to-end product line engineering.

48:21 We want to break the silos. We show different tools. We show a digital thread. Now, what I want to highlight here is that, we have, like- pure variance in the PLE engine, but you could replace. We are an open ecosystem. You could replace the MBC tools. You could have another, application life cycle management solution, and eventually another, PLM system. So we want to explain the concept here, and not just focus on the specific tools. What, what I want to alight is that highlight, that this is the PLE engine that drive the transformation, that drive the variability, that manage the variability.

48:54 And what I will do when we will share the slides, I will also add the link here to show which are the, other connectors. Pl- more than 20 connector are supported by Pure Variance. So as I said, this is an open ecosystem. You can plug and play, of course, with different capabilities, with different level of integrations. And, being PTC, it would be easier because, of course, we, we for us it's very important to have a consistent PLE end-to-end approach, starting from requirements and going up to the

49:26 PLM domain. So if you are interest about that, please, let me know. Get in touch with me, and, we can go into, the details, and we can analyze your specific context, PLE end-to-end context, including the tools that are involved. Thank you very much. So I think we have, five minutes time for some questions, Andy. Thank you for a great presentation. Thank you. W- we have some questions in. We'll probably only have time for two or three. So I'm gonna start off with one.

49:56 How do you address the customer needs, faster, cheaper, customized, steeper ramp up, in case of a system of systems architecture beyond traditional vertical integration? For instance, as collaborative, a collaborative network of companies like OEMs, Tier X suppliers, and sometimes competitors. Who wants to answer this question? Luca? April? I can take a stab. I mean, right now I would say- Please we have

50:27 not solved it, right? A lot of the customers are trying to control their own uncertainty by telling us what tools and reference architectures they wanna use, and they don't all pick the same ones, and even similar customers don't pick the same ones, right? So it's kind of evolving, but one of the, the things at a smaller scale I've seen work is where we can manage the interfaces, kind of like you almost take a, a most of flavored approach to what who's building what pieces. You, you can agree on the interfaces, and then kind of work within your own box.

51:00 The customers all have their own different tool stacks, as our competitors do. So just the infrastructure side of that can be really tricky. So I would say if you're trying to do that, start small and early, 'cause even things you don't think Like, it can get down to the images on the computers. Everything else looks like it should be fine, and it still isn't. So I, I don't know. I mean, it pe- not everyone is ready for PLE, so I that's one of the other things, is it can also be one of those things you do behind the scenes. Like, you saw Marco do a transformation where he had a bunch of stuff, right?

51:32 And then he delivered a point solution. So there's, there's ways to actually everyone kind of manages their own variations, and if they each deliver a point solution, you can still have a collective answer. But knowing what those variation points are and agreeing on them is challenging, too. So that's a really good question. Um- it's not something I've seen solved well at scale, but I'll hand it over to Luca if you've got something to add. I can add a bit to one point. What I present for the interior market, for the aircraft interior market, is the same

52:03 product we have asked, but as well as OEMs, okay? Therefore, we engage some discussion with OEMs, because, we know that we have to face the same issues. Therefore, we are discussing how we can collaborate, and working together to coordinate us in this kind of, variability, and propose something that could be useful for both and the customer as well. Yeah, well, I have one go back. I have seen it at least start to work, and one of the big enablers there was culture.

52:34 So if you have a unifying agency that's pulling all those networks of companies together, and the tone of their messaging is, "Work together, it's important," and, and they can kind of create that safe space for companies so no one's feeling like they've got to hold their cards close to their chest. I've been in some sessions with some of our competitors, and we act like one team, right? Like, it When we have a common goal for that customer, it's, it's not like it's impossible, but I do believe it kind of starts from the top of all of those companies saying, "Take

53:06 off your badge. Let's, let's solve this problem for them." And that's a big enabler, and you'll be surprised how much you can get done if you, if you get that going for you in the beginning. Okay, so we have a question. Given Lockheed Martin's extensive legacy and scale, how is the company balancing internal organiz- organic innovation with strategic acquisitions to compete with agile startups dominating next generation AI-driven defense technologies?

53:36 All right, so this is where we're gonna reemphasize April's opinion for Lockheed Martin's official position, okay? I'm just seeing good, committed folks trying to do good work for our customers. So I don't know that there's an official position or a balance, but we're a huge company, right? There's No one knows everything that's going on. So some people might be trying to incorporate Agile, and other people might be, you know, working a different problem space. So it's Each individual, right, they basically say, "Hey, let's everyone lead from

54:12 where you're at." So that's what I see people doing, right? They have an area they wanna grow or learn, or they think we could do better. They raise it up. You know, sometimes we get funding for things, sometimes we don't, and this happens at all the different levels of hierarchy at Lockheed. And sometimes we, we get to learn. Like, we have a big initiative right now going on where we're kind of tearing down some of those BA stovepipes a little bit. And so there's ways now where everyone can be made aware of other things each other are doing. There's still hiccups, but it's really increased our ability to collaborate and understand who's doing what, and make sure

54:45 that we pull together a bunch of different vantage points, and also not pay to do the same thing three times. So- We're still evolving, right? It's, it's, it's a challenge, but I, I think our innovation is something that we're proud of. We also know we wanna get faster for our customers, so everyone is just taking that on themselves, and you, you see evidence of it in our, our communications and the emphasis that our leadership puts on it. So I think we're a work in progress there. There's no one straight answer for how to balance it.

55:16 I'm sorry. Okay. We're, we're out of time. I'll pass the other two questions to you, so that you can, get in contact with the questioners and answer online if you Or, or offline, rather, if you want to. Oh, thank you. Yeah. So can we, get to the next slide, please? Again, thank you for, again, for this informative presentation, and thank you to the

55:48 audience for your questions and your time. As we mentioned earlier, you can now find the previous webinar recordings in the INCOSE library, and you can now claim one PDU credit, towards your systems engineering professional recertification by attending this webinar. You may also claim this credit retrospectively for INCOSE webinars that you have attended and where attendance meets the qualification requirements. Again, I'd, like, to express my, a very special thanks to, PTC for their generosity in

56:20 supporting this INCOSE webinar. Thank you again, and we hope to see you again soon.