The application of Model-Based Systems Engineering – ep. 2 Transcript
In this second episode of the model-based systems engineering (MBSE) series, I am joined by Tim Kinman, Vice President of Trending Solutions and Global Program Lead for Systems Digitalization at Siemens Digital Industries Software. We are also talking with Ryan Wilkins, Solutions Consultant at Siemens and Tony Komar, PLM MBSE Evangelist at Siemens. These experts discuss the requirements-driven design and the functional definition in model-based systems engineering.
We will learn how model-based systems engineering (MBSE) transforms the industries’ approach to the design and build process. We will also discuss the importance of supplier collaboration and the role it plays in the product development process and learning how agile development complements the MBSE goals.
Please learn more in the transcript (below) or listen to the audio podcast.
Read the transcript
Nicholas Finberg: Today we’re going to explore conceptual design, where early business and design decisions are being made. Can you please explain to me what requirements-driven design means in terms of Model-Based Systems Engineering?
Tim Kinman: Hi, Nick. So, I think what we want to come back to in concept design is really the beginning of the product definition, and that does include requirements, and it includes other elements of how we represent the scope of the product that we’re trying to build. And this whole thing starts when we are dealing with rapid response to the voice of a customer, the need to quickly respond to market dynamics. And we need these types of representations in product definition that allow us to assess changes to the product. So, I think everything we’re dealing with here around requirements and concept design really evolves around how customers, specifically complex products, need to rapidly respond to market dynamics and market needs. And using not just requirements but the related models in product definition to help them make that type of assessment. So, a long answer, but I guess that’s a way to respond to your question.
Nicholas Finberg: Thanks, Tim. One of our other guests today is Ryan Wilkins. Do you have anything to say?
Ryan Wilkins: Hi, Nick. Yeah, I will just say in addition to what Tim was just speaking on. When you say requirements-driven design, I think, for the traditional product development or product definition phase, that’s typically been tied right to some mechanical CAD designs. But I think now as we’re talking about Model-Based Engineering and Model-Based System Engineering, requirements-driven design starts even further, and it really ties into system modeling and functional architectures. So, I think requirements-driven design is a lot bigger role in this because you’re trying to use requirements to help optimize and tune all of the different models that you’ll be using as you’re developing the digital twin of your product.
Nicholas Finberg: Thanks, Ryan. Hey, Tony, do you have any thoughts on this?
Tony Komar: Yeah, it’s really quite an interesting discussion topic right now. Traditionally, we have done very strict requirements we’ve done first, and then you started working on the architecture. But we’re seeing a change right now where people are using models more liberally, and they’re actually looking at trying to figure out what comes first. And in a lot of cases, what’s happening is the changes coming to they’re actually starting to model at the same time they’re writing requirements. And the benefit there being is that they have a good solid reference point for writing requirements. So, as companies embrace agile methodologies, we’re seeing this modeling is starting to emerge. Now, at the same time, the requirements process is basically being done.
Nicholas Finberg: So, agile, that’s super common with software. And it’s great to start working at another place, but it can look kind of chaotic. Can you speak to any of that?
Tony Komar: Agile sometimes has that connotation that it’s chaotic. But there are some scaled agile frameworks, is one initiative that basically helps give discipline to that agile process. The idea, basically, is that you still, even with agile, have an architecture that you’re kind of putting in place. And basically what it brings to you when you’re writing requirements is it gives you a reference point; when you start referring to things that you’re defining with shell statements, those nouns that you’re using are in the architecture. So, by having that model representation, at the same time, allow us to develop a more consistent-looking set of requirements specifications.
Tim Kinman: I think just to add to that, Nick, in this whole area of agile, people often talk about the known unknowns and the unknown unknowns. And basically, that saying that it’s very hard to understand all the elements of the product that you’re trying to build on the first day or all the elements of the behavior of the problem that you’re trying to address on the first day. So, agile gives us a great way to do some time boxing and allows it to sort through that, as I said, the known unknowns. Sometimes we’re aware that there are elements that we just don’t know what we’re we needed to be doing. And there’s also these unknown unknowns that you just trip over along the way. And so, agile is a fantastic way to allow people to move forward in a timeboxed way without the fear that they have to know everything on the first day. But also, as Tony’s talking about, we’re using models to allow us to explore that and discover the response to the known problems and also discover, in many times, the unknown unknowns that are lurking.
Ryan Wilkins: I definitely agree with what Tim was just saying. And I think what’s really interesting, Nick, you brought up earlier, using agile development for software. Obviously, agile development has been used quite a bit in the software development world and quite successfully. But I think what’s really interesting is now we can start to really escalate or pair up agile development with Model-Based System Engineering, and we can start to use the scaled agile framework that Tony was talking about earlier are safe. And like Tim was just saying, you can actually create these tangible building blocks, all the way from marketing and customer needs, and streamline that process of getting that input directly into your portfolio plan and translate that into features and the function, and eventually, the systems you need. It actually develops the technologies with and through an agile development plan. And using that methodology can really help you make that process more efficient when you’re developing your new technologies.
Nicholas Finberg: Oh, that’s a lot more of the business than I thought it’d be. That’s a lot of concepts and explaining to do beforehand. Is there a common methodology for sorting through this in a wider project group?
Tim Kinman: Yeah, I think there’s plenty of methodologies for agile, in general. I mean, you can agile anything. But I think the key part is how do you get started with complex systems where system engineering and MBSE are part of that? And I think those techniques could be many things. Some people may be starting with an existing product and they’re looking for points of innovation. So, it’s a little more contained when you have a market problem that requires you to extend an existing product. But you may also have points of innovation of whether it’s an existing or brand new product that is highly complex. And I think the way people get started many times is, “Do I really understand the problem space?”
Even modeling the problem space, thinking about, “Do I have the requirements properly represented that articulate what the market, what the customer, wants the product to do? Or do I have the functional view of what the product needs to do to satisfy this?” So, getting started many times is clearly understanding the problem that you’re trying to address. Because without having the modeling of the problem is very difficult to have confidence that you know what the product is needed to be built? I mean, others can chime in. But again, I think it’s getting clearer in using models to clearly understand the problem space, the requirements, and analysis of functions, and clarity of the simulation – that’s an important starting point.
Ryan Wilkins: I agree, Tim. And I think it’s really like you’re saying, it gives you the ability to define what’s needed up front in your product, and have the teams collaborate – gives a certain level of input. And then in an agile way, go do some sprints, and dig into your models, and use that as a way to optimize and tune the performance of the system you’re working on or even at the product level. And so I think that’s what teaming up agile development with Model-Based System Engineering allows our customers to be able to do.
Nicholas Finberg: So, what kind of models are you guys working with in that situation? Is it physical, or they’re non-physical models?
Tim Kinman: Well, we’ll start with non-physical. I mean, moving from specs is one big change. We’re moving out of documents into models, and the models could be requirements models. It could be a representation of requirements that have behavior and relationship associated to those. So, models could be requirement models, they could be functional models that could be in a network or a hierarchical view of interrelationships. So, yeah, you start with non-physical because, as I said, you’re scoping the problem space first. And many times that problem space is represented by models that involved operational or functional use cases. And that’s a key starting point.
Ryan Wilkins: And I think that’s really important also here that you’re starting with a model of how the product is going to work in its environment, or an operational model, as opposed to maybe starting with a bottom-up set of models and starting in the more physical world. You’re starting in this non-physical world with models that are really describing, again, how the product is going to work in its environment, how customers will perceive your product. So, you’re building up these operational models, and you’re then using that with the requirements as a way to define how the product should be performing.
Nicholas Finberg: I think I’m getting it. Do any of you have an example of what this might look like in the real world, maybe aviation or automotive?
Tony Komar: Yeah, an example of possibly in the aviation domain would be, you could start with an operational-level model that really depicts the different people have to interact with the system you’re working on. So, for instance, if you’re working on a missile or something like that, you still have to feel it, you have to load it onto the aircraft, you have to take it off the aircraft, and you have interactions with ground support devices, interaction with ground support people – those things, you still have to do. And that’s really kind of the operational analysis of it. And that’s important because it’s those operational activities of, let’s say, the personnel touching the device and interacting with it.
It means you have to have functionality for requirements, you have to have requirements defined for human factors type of things. Basically, be able to get access and to do it because you want to reduce the amount of time it takes to do the servicing of the device, just feeling it, for instance. So, that’s an example of an operational analysis where you’re really worried about all the different entities and actors that have to interact with the product that you’re working with, and so it’s an extremely high level. From an automotive perspective with autonomous vehicles, it could be starting planning the mission – how do you go ahead and plan? If you have a delivery vehicle, how do you basically make the delivery vehicle arrive at a certain destination to perform a task? That’s that level above. That really kind of gets into this idea of operational analysis of it.
Nicholas Finberg: And that leads into how you define the more physical aspects, okay.
Tim Kinman: Another simplification of this whole thing often is, if you think about the way that people would interact, let’s say, it’s two people talking to each other and you’re trying to transact, the what and the why is the first part of the conversation. So, somebody as a customer, somebody in simple terms would say, “Here’s what I want. And here’s why I want it.” And you begin that activity of modeling – how you want to measure that, how you would verify that you can achieve that – and then for the person building the product, they start reflecting how they’re going to satisfy your needs.
So, the most simple way, when we think about these examples, like Tony has mentioned in UAV, is that one end of the transaction is somebody expressing in model-based terms, the what and the why, with a way that we can measure and execute and simulate that we can represent. And the other party is responding with a How – how am I going to satisfy that? Well, that’s where we start bringing physics models in as well because the How is a combination of architecture. And in the architecture, it will also start tying into some of the physical elements that would be in response to the How.
Nicholas Finberg: You’re bringing in lots of different domains; you might have electrical, you might have mechanical, software, definitely in newer products, that’s very common nowadays. How do you define what those different functions are for the systems?
Ryan Wilkins: So, I think if you take the example that Tony brought up, especially for automotive, I think ADAS -or advanced driver assistance systems – this is the easiest one, I think, to be able to apply this type of operational modeling and connection into physical. So, like Tony was saying earlier, you may have a delivery truck, or you may even have a passenger vehicle that needs to achieve a certain mission. Some examples we’ve done in the past are things like Active Park Assist or Emergency Braking. So, we actually put together an operational model that started with a vehicle parking itself. And then you can start to add different things from the environment, different noise factors like a pedestrian crossing the street or crossing the sidewalk behind the vehicle, and how should that vehicle respond when you get these different noise factors. And you start to build that in your system model very early on. And you start to then translate that into the different capabilities that your product is going to need in order to respond to those different things that are going on in the environment.
So, if the vehicle is trying to park itself and a pedestrian walks behind the car, it needs to stop. So, you start to build out these different capabilities, you start to identify certain functions like the car stopping. And then you start to allocate systems to achieve that function or to implement that function. And that’s really when you start to get into the How; how am I going to make sure that this car stops? Well, I need to sense the pedestrian, and then I need to go and tell them brakes to stop the vehicle – the brake controls. And so as you start to get in and synthesize those different systems or components that are going to achieve or implement those functions, you can then start to get directly into the physical architecture and exactly how you’re going to implement some of these capabilities at a much more granular level.
Nicholas Finberg: Okay, perfect. How does this factor into the number of ECUs in a vehicle? I know that’s been kind of a problem recently, is there any work to try to consolidate the number that they’re using to just limit the amount of silicon in a vehicle?
Tim Kinman: Before we jump in there because I think we’re getting into more of deeper into How. I think there’s a lot of other elements that we need to kind of flesh out here. In the product definition, again, let’s go back to the What and Why. And what Ryan was talking about in the What and the Why is that we had these models that are describing what we want the product to do and the constraints of why we wanted it to work that way. And that’s going to be mission models, it’s going to be requirements models, it’s going to be functional models, operational models – these are all the things that are the What and the Why. But when we start determining connecting to engineering, that’s where the functional decomposition is going to give us some insight into “Is this function going to be satisfied by a software action? Is it going to be satisfied by a physical action?”
We start getting some insight into how we want to represent those functions in the actual product. And I think when we start breaking that down into architecture, that’s the first entry point into really laying out the How element of the product that you’re trying to build. So, I think, we should explore a little bit here about architecture and the importance of architecture as we are dealing with product definition. Because architecture is really a key entry point into product engineering because architecture from a logical standpoint can start at the very beginning and sketch an outline of how the product may be built. But when I get into the next level of physical architecture, that’s when I really started tapping into the domain expertise to help me flesh out that detail.
Nicholas Finberg: So, you’re creating a group of things that you need to put together in your vehicle, and then you start pushing all of those requirements out to the necessary groups. That’s a lot of scope for a project. Is there a way to kind of limit how much time is spent on these upfront models to deploy them? Or is it more on the backend that you want to be able to reuse all of this stuff after you put in the time and effort?
Tim Kinman: Well, you’re simulating from the very first day. So, as we talked about earlier, we want executable models. So, we want to be able to do simulation on the What the Why. As that progresses, we also want to then move into architecture. And so that we begin simulating the How element of the product, and that’s when you bring in things like multi-disciplinary analysis and optimization, that’s when you bring in other elements of electrical architecture. This is when you start exploring, to your point earlier, “Am I going to have an ECU to actuator and point to point? Or am I going to do zone-based ECU? Or am I going to do centralized?”
That’s all driven based on the requirements you’re trying to address, the What and the Why you’re trying to address. And then you start architecting to determine how that product must be engineered? So, I think that’s part of the key element of when is it good enough? How do you get started? You get started on the first day when we talked about agile, and then it evolves and matures over time as you gain confidence that you have, the coverage of the What the Why, the requirements, and operation models. You start to then see the coverage of that in the context of the architecture and the physical elements of architecture also through simulation.
Ryan Wilkins: Right. You want to be able to simulate, and you want to be able to optimize as quickly as possible. What we just talked through, really, was, how do I build up a way and blueprint for how I can leverage all of this traceability between requirements and features, requirements and systems, requirements and components, and build up this network of traceability so that I can get all the way down to specific parameters that I want to tune and optimize? And when I derive my simulation, from this work that I’ve been doing, I’m able to take those parameters, bring them into a simulation, do some type of optimization and analysis almost like a design of experiment type of analysis, bring those parameters in, and then start to actually optimize my product performance based on different parameters that I’m looking at and exploring quickly and easily.
Tim Kinman: So, a good example, Ryan, there’s one that I know you’ve worked on, is this whole area of how would I integrate a new feature into an existing vehicle? Let’s take a product line, an existing automotive line that now you want to add either assisted driving sensors or you’re adding more ADAS related. So, an example, maybe you can walk through is, of everything we’ve said: the What, the Why, the How – how they’re interrelated? Now you want to add a new feature into a vehicle, how would you do that? Where would you start?
Ryan Wilkins: I think the first thing is, like we were talking about earlier, what is it that we need to do? And as you start to decide that “What it is you need to do,” hasn’t been realized yet in the product. Like we were talking earlier about some type of advanced Active Park Assist type of feature, where it’s parking the car, maybe doing parallel parking or perpendicular parking. And not only that, but it’s also able to stop and start the vehicle as pedestrians are passing by. So, if you go in there and you say, “We don’t have that capability today. We’re going to go develop that capability.” I think what you need to be able to do is scope that work for that Active Park Assist feature in this case. And also, be able to take the requirements and the architecture and pair those up with some type of simulation analysis.
And you really need to build a package that up, take a team, go do the sprints that you needed to do, and get to a point where you’re comfortable with the performance of that feature, but at the same time, you’re going to be reusing functions. So, we talked about being able to stop the car when a pedestrian crossing the street when you’re parking the vehicle. That’s something that you may be reusing from another feature like we’ve done in the past – emergency braking. And so there’s a certain level of reuse that want to enable in this whole process as well.
So, as you go and develop this new feature, 80% of the functions that you may use, they may be reused, and the other 20% may be new. And so, as you go to release and integrate that feature back into the product, one of the biggest things you need to know is don’t have too many functions assigned to any one control system; “Am I overloading my controls?” Then you need to be able to go into the architecture and analyze, “Am I over allocating and overutilizing my different control systems?” So, that’s one of the bigger vehicle integration problems that you need to be able to solve when you’re integrating features into the product.
Nicholas Finberg: So, how does that play into having so many suppliers and in an automotive development program? You might have one group working on the sensor block for the ADAS, and then you have someone else working on something that still references all that code for stopping or maybe deceleration curves? But how do they talk to each other?
Tim Kinman: One of the things is how you define interfaces between these functions and relationships between the subsystems and components? Because in traditional geometric, you’d have meeting conditions. It was a physical thing; “How does this mount? Or how does the kinematics work?” But it was very contained. Now, we have non-visible things transacted across the supply chain. It could be that the supplier has to think about what signals are they receiving? Or where are they in the network and what are the computational or the latency requirements? So, the contract with the supplier, and even internal contracts, is really about how we are defining the interfaces, which are also part of the model-based representation, but how we’re defining the interfaces between those functions, and that indicates what they agreed to do in terms of exchange of behavior and exchange of non-physical elements between those functions.
Ryan Wilkins: I think that one thing that we’re able to do here is we just talked a lot about the ability to have a better model of what your product needs to do. And you even have multiple things built into your model of why your product needs to do that. And I think as you start to decompose that into certain modules that are systems or subsystems, and you start to deliver that to the suppliers, they have a better picture of what exactly you’re trying to achieve overall.
And that allows them to go and have a certain level of freedom in their designs and optimize their designs and their products, as opposed to what may have happened in the past, which was, someone developing a vehicle may have said, “I need this component specifically.” And the supplier goes and develops that component specifically, within a very strict constrained box. Now, they’re able to look at the problem overall and really have a lot more design freedom to design for the feature, the capability that needs to be integrated into the vehicle. So, I think that allows you to get suppliers involved in the product development process a lot earlier on and shift that process to the left.
Tony Komar: I’ll echo that too. I’ve recently had the pleasure of working on an electric vehicle cooling prod model that I’ve been developing. And one of the interesting things that’s coming out of it is that you must step back. And that’s where, again, modeling, basically, the functionality that you need, and having a more abstract look at the problem is really important. Because if you don’t step back, you’re going to be stuck in the way you’ve done it before. When you think of an internal combustion engine, you basically have a huge heat source. So, the problem is mainly just trying to get rid of the heat, and then use it in channel what you need and get rid of the excess. When you go to an electric vehicle, the problem changes dramatically; you don’t have as big of a heat source.
Yes, you do have that’s heat generated from the batteries, and you have heat being generated from the motor. But it’s nowhere near on the scale that you would have had with an internal combustion engine that basically is managing explosions of gasoline. So, that changes the problem so dramatically. It’s great to be able to model it from a high-level perspective, thinking of, basically, you need a thermal management system for the car, it’s not just a heat management system. That’s some of the challenges that you get into with it. And it’s better to be able to have a modeling type of capability that allows you to think in that more abstract format and then allows you to go into “What are my options for it? And how can I deliver it?” And being able to use models, especially, to be able to predict the size of the solution you need for this new domain really helps you to find more creative options, and using especially suppliers to help do that. The OEM’s job then is to kind of develop this higher-level view of what the problem is that they’re really solving.
They all need to come up with an idea of what exactly is going to be the heat production from the heat flow from, let’s say, one part of the system that you may be getting from one supplier – the motor – maybe the battery – an idea of what the battery is – and then leveraging models to help you figure out what’s the dynamic behavior of these things, under load, what’s basically going to be the maximum power or heat generation that’s coming from the vehicle, and basically, do I have a way to dissipate that? But at the same time, the other side of the problem is you may actually need heat.
Especially, in a cold start situation with an electric vehicle, you’re going to have to have the ability to warm the batteries or to keep the batteries warm, so they are at the most optimal condition. So, it changes the problem dramatically, and the OEM’s job is going to be complex in the sense that they need to basically look at that problem, characterize it, define the boundaries with requirements, and then pass that on to suppliers so that they have the freedom to be unconstrained, to come up with a solution that will best meet their needs. So, the OEM’s job role is going to be more around defining what, let’s say, the thermal management system has to be. They don’t just need a cooling system; they need a thermal management system to solve that problem.
Tim Kinman: Maybe I was thinking more about an example of a sensor. Because I think the heat part, we can see and have some technologies about how we deal with thermal but I was more thinking about the OEM putting together a sensor that came from Supplier X, where that sensor is sending the signal that will eventually go back to the emergency braking to stop the vehicle. So, that’s what I was more trying to understand more from you is how does an OEM take that, where the verification of that is “I get this sensor, it sends a signal, it sends a signal on this network, the network in the wiring may have come from a different supplier, and then that goes to an ECU, which came from a different supplier, that then controls an actuator that triggers the brake, which came from a different supplier.”
So, there’s a whole connection of things that you need to verify that have a combination of physical and non-physical things that will achieve that function of emergency braking. So, I’m interested in any thoughts you have about how does an OEM, how do they model that in a way that they know that the suppliers are developing the right individual components, and then when they bring it back together, they know that those are going to satisfy that higher-level function that we’ve been talking about? Is that where architecture and how we decompose the simulation elements of it, is that where that comes into play? Seems like it is.
Tony Komar: Yeah, absolutely. Basically, having all those pieces well-understood and bounded, not only affects your modeling from a more of a system model but also down into a model that basically represents the physical components, and basically helps you characterize those. One of the roles that a lot of OEMs get into is they’re the ones that are actually doing the first of anything. They may be doing an advanced product as kind of understanding what the capability of the technology is. And it may be advanced, not only in a physical product but it may be actually just in models. They’re defining what the state of the art will be, and then they use that information to set the standards for the suppliers that have to then develop the product that fits into that vision of what they have for it. And that vision eventually is what drives their testing that they’re going to have downstream on that.
Nicholas Finberg: So, OEMs are integrating all the systems. And then I’m pretty sure Ryan said something about tier one suppliers and trying to preempt some of the needs of OEMs. Is there anything else that MBSE draws in in the entire supply chain for automotive or really any product in general?
Tony Komar: Yeah, one of the things you were talking about that, also, you need to bring up is that, basically, automotive suppliers are also looking for new ways and new innovations to basically improve income. And one of the things we’re seeing is that because of the software influence, you’re seeing the ability to basically upgrade the vehicle. And we see things like upgrading the vehicle from a software perspective. But now, we’re actually getting in the ability if you can look at the problem big enough is that they could upgrade the vehicle with features. So, for instance, I have an offroad vehicle that’s capable of that but when I bought the vehicle, I bought the regular standard highway features for it. It would be interesting if it was possible for the dealership to basically notice that I’ve taken the vehicle off-road, and then offer me options that I could include into the system and add that capability to it.
So, you’re basically now offering something after you have bought the thing but from the same vehicle supplier, that could create a new revenue stream for them, and look at the problem in a different way. They know that the parts should fit together, but why not have them recommend it. And with the capabilities we have now of vehicle information that’s being collected, that’s over the web, they can actually make recommendations based on my behaviors of how I’m using the vehicle. So, it goes into a much bigger model than just the vehicle. Now, we’re extending the model into basically beyond the vehicle and how I’m using it with the users.
Nicholas Finberg: Well, we’re getting to the end of our time today. I want to thank all of you guys for joining me. And I look forward to talking to you again, there’s so much more to talk about for Model-Based Systems Engineering.
Tim Kinman: And, Nick, I guess maybe in the wrap-up, maybe some of the key things we want to bring back is the importance of product definition. Because product definition is our approach for representing the models that can be executed for explaining the What and the Why, like, “This is where we get into requirements and in functional models, and it’s really representing the What and the Why.” And it also ties function to physical as we now bring in architecture, because now that architecture that begins evolving allows us to connect the What and the Why and the functional model representation to the physical elements that is represented by architecture in the interfaces that are represented.
And that helps us do the decomposition, the decomposition to modularity that allows the collaboration across the engineering department, allows the more efficient collaboration in my supply chain. And then with that, we have an ability to execute, in a way, that we know when we integrate these elements back together, we go right back to the What and the Why is the measure. And we use that as a measure of verification that we got it right and it’s all driven by a product definition that drove the initial action, and a product definition that is then used to verify that you’ve achieved that result.
Nicholas Finberg: All right, thanks, Tim.
Tony Komar: Thanks, Nick, for giving us this opportunity to get together and discuss this topic. It’s especially nice to be able to get discussions like this going. It’s been a long year. And having a chance, an opportunity to get together on a call and discuss these topics with my peers is great. I appreciate you coordinating this.
Ryan Wilkins: Yeah, I think this is a really good way to have a roundtable discussion on not just some of the ways that we’re working on the problems today, but also be able to really relate that to some challenges that we’re seeing in the industry and challenges we’re dealing with our customers daily. So a really good discussion that we just had. I really enjoyed it. Thanks again, Nick.
Tim Kinman: And Nick, thanks to you as well for hosting us through the session and guiding the conversation. And thank you very much for your leadership in that.
Nicholas Finberg: Thank you, guys. Have an awesome day.
Siemens Digital Industries Software is driving transformation to enable a digital enterprise where engineering, manufacturing and electronics design meet tomorrow.
Xcelerator, the comprehensive and integrated portfolio of software and services from Siemens Digital Industries Software, helps companies of all sizes create and leverage a comprehensive digital twin that provides organizations with new insights, opportunities and levels of automation to drive innovation.
For more information on Siemens Digital Industries Software products and services, visit siemens.com/software or follow us on LinkedIn, Twitter, Facebook and Instagram. Siemens Digital Industries Software – Where today meets tomorrow
