Welcome to the latest episode of Reimagining Mobility. I'm here with Andy Roberts, chief engineer for Systems at Mobility Technologies at AVL So Andy, tell us a little bit about systems engineering. Okay. Seems like it's a big topic right now. A lot of people are talking about it. Tell us, what does it really mean? What systems engineering really mean? It sounds really good. It sounds very important. But maybe just many people don't really know exactly what that means or how AVL looks at it.
Absolutely. So, yeah, I mean, I think systems engineering really is is the approach, the discipline of looking at whatever you're developing overall as a system, not as individual components, not as elements of their own, that you develop separately, but more as an integrated forward system.
And if you deal with it in that way, if you look at it in that way, you end up with a much better product, more integrated products, a more efficient, I would argue, a more robust product rather than as individual components. So as far as systems engineering at AVL I think like most of the certainly automotive industry, it's progressed quite a bit over the last maybe ten years.
Originally, systems engineering really came from a I would say a controls a software development sort of approach where it was very much used to define, you know, what the software needed to do. So we'd, we'd look at a high level of say, say like an engine controller and say, okay, what does the engine controller need to do? We'd capture some requirements for that. We'd then break that down into what the hardware needs to do, the software needs to do, the sensors needed to do.
And then we'd we'd use that to develop software and under controls hardware as well. And now I think it's really being adapted across the automotive industry much more broadly. It's still a big part of software development, but it's also really key, I would argue, to hybrid system development and system development, and that really is driven by the complexity of the systems and the interaction between the components, between, say, the powertrain and the system, the off board system as well.
That GPS, the connection to the infrastructure. I just wanted to ask. So does it include the cloud then as well? When we're talking about AI in the cloud, especially for autonomous driving, when we're talking about telematics for route calculation, where is my next gas station? Where is my next charging station? Is it open? Is it working? So does it include the cloud as well, not just on the vehicle? Yeah. So from I think the inclusion of the cloud. Absolutely.
So if we took an example of of a system where where we need to understand the range of the vehicle. So you could do that very simplistically. You could say, well, I am traveling from point A to point B through my GPS I've put in my route and it's 300 miles. What's the range? You know, what's the state charge? My battery and therefore what's the range? But in reality, you want to be able to bring in the GPS information.
You need to be able to bring in the traffic information, the gradient of the road you also. So that's that piece that needs to come in from the say the off board, the GPS and related information. But you also need to understand from a powertrain perspective, what's the charge of the battery, but also what's the state of health of the battery?
You probably also want to understand how the driver historically has been using the vehicle, driving the vehicle, because that will obviously affect, you know, on that to the bone. Through the activity of a. Yeah. So he he may be or she may be getting less mileage out of the battery because they're being more aggressive in the way they drive. So really, now what OEM vehicle system developers are designed to bring all that information together.
So the off board, the powertrain information, the battery information, how the driver is driving the vehicle and you know, you need to bring all that together in a systems approach. So you need to understand from a higher level what's the what's the requirement, what we need to understand what the range of the vehicle is over a defined route.
How do we do that where we need to bring in GPS information, we need to bring in powertrain information, battery information, bring all that together into an accurate calculation that can then be be used to predict what the range of the vehicle is. So for many years now, I've been leading teams that always talk about model based systems engineering. And for many years, I felt like every time I asked for details, I felt like, okay, yeah, I get it. But are we really using models?
You know what I'm saying? And I felt like it's it's almost a little bit like big data. Everybody talks about big data. Everybody collects big data. Everybody does a little bit with big data. But I struggle at times to really see what we're doing with truly big data mining. ID like going through the data, mining it. Using it, yeah. Tell me a little bit about model based systems engineering, where we are now was maybe opposed to, let's say five years ago. Yeah, absolutely.
So I think model basis, model basis engineering has been talked about a lot five years, maybe even more than that. And I think there's been some some usage of it. So I think my experience in more of a limited fashion, but in recent years, maybe the last year or so, really, I've seen a big increase in the use of. Okay and the use really of, you know, a graphical way, I would argue to to represent requirements. And unlike Visio, the tools are used for model based engineering.
You could use this year to to draw architecture diagrams, interface diagrams. But the real key thing with model based systems, engineering tools approaches is that all these different diagrams are linked together. So you change one, it changes in the other. Diagram, automated. And automation. Obviously you then also link that to your textual requirements as well from a control is effective.
You know, it's even getting to the point where you can start at the top level of your set of requirements, maybe textual link that into your model based approach to cascade that down to to your different, I would say architecture and interface views and even down to the level where you can define a a controlled architecture within a model by systems engineer tool and actually then take that architecture and then deploy that or I guess export it and then start actually developing say in Simulink
in that architecture you design defined from a from the systems perspective. Okay. So it's certainly becoming, I would say in most projects now actually we are starting to see activity aggressive to you. I just want. To ask if you if you if you if you had to guess, what's the percentage of projects we're doing for customers or with our partners that use model based versus just the let's call it the standard systems engineering approach? Is it 80% use model basis, a 60%?
Or I would I would say probably say 50% or so. But it seems to be more I mean, I think the the ADAS kind of projects are certainly adapting, adopting some of that more quickly. Well, though, into the powertrain domain as well, it is certainly becoming adopted as well and it's pretty powerful. It's a a very good way, I think, for people to quickly understand what the system is and the interactions much quicker. Obviously to understand a diagram, a graphic, a, you know, an image than than words.
So yeah. So what we are, we see ourselves as pretty strong at model based or systems thinking. Let's just keep it generic systems engineering. What do you believe makes us good at that or makes us so good at that? What makes us unique is it is it our background in lots of different domains in the mobility space? Is it the domain knowledge of individuals that then brought together bring it?
Or is it is it the flexibility and the the wide breadth and depth of knowledge that our people bring that allows them to do that? I mean, I would say it's all of those things. Certainly the expertize and the deep knowledge in the different disciplines is a key part. But the other thing is, over the last well, certainly ten years or so, there's been a very active progression of defining our systems engineering approach. How do we do systems engineering?
So across aviation, globally, I've been involved in a number of the team in the US, have worked with the teams in Europe and China and everywhere else in the world to develop and agree a way that we do systems engineering. To a common way across all of. AVL Absolutely. So I mean, that is that has to be a well, it has to be certainly adaptable as well. So it has to be scalable to the different projects we've got.
Every project generally is different, so we have to have an approach, a way that can be scaled to be used on all of these different types of projects, whether it's an ADAS project, a conventional powertrain, a hybrid powertrain project. We have to have an approach that is common and understood globally by by the systems engineering team and the teams working with us as well.
So it is a it is a also it allows that we can work globally together as well because if we're working in the same way we understand the same way of working, then the US, Europe, with China, everywhere else in the. World as well. What, what makes a great systems engineer as an individual? Is it is it the experience? Is it the ability to think low level but also higher level from a complete system?
What this thing is that a has to design is it is it the mentorship program that we have where you and others mentor people? Is it they need to rotate around first to lots of different groups to be able to understand the different components? But what makes a great success? I mean, I would I would argue that what makes a great system engineer a part of that is an interest in the overall system and all this. Okay. I mean, some people really like to get into the real details of one specific system.
That's great. And we absolutely need those people and know we have a lot of hugely talented, real technical experts in certain areas. I think systems engineers, most systems engineers that I work with, like the overall understanding everything really, they like to see the big picture but then be able to take that and sort of dig down into what makes up big picture, you know, a hybrid powertrain. You've got to understand internal combustion.
You've got to understand electric drives, inverters, DC, DC, maybe if it's a plug in, you've got to understand onboard chargers. I think having people that are real have a really got an interest in a passion to understand that that's really makes a really good systems engineer.
But then also to be able to, to work in a methodical way, to be able to go from a high level, maybe vehicle level description of what's needed and be able to rhetorically break that down and to say, work from a vehicle perspective, we need this. What does that mean from the powertrain, from the chassis? Yeah, I think that's really quite key.
When you take two different systems, engineering projects, let's say you have done give me an example of an extremely complex one, an example of maybe not an easy one, but a more, let's say, easier to apply systems engineering approach to it. Yeah, sure. I mean, I think the ADAS project, so when I'm working on is a lot of complexity there because you have got to obviously there's lots of ADAS features.
So whether it's AEB, FCW, ACC, all these features have to we have to understand what they each need to do. But then when they all have to work together in conjunction, they also have to then work obviously with the powertrain as well. There's elements of off board information we're bringing in. There's a perception system. So we need to be able to clearly define what is needed from the perception system. So that's those are pretty complex projects and hugely interesting for that reason.
I think the more simple, straightforward, I mean, transmission projects, we've used them. I wouldn't say the super simple, but. Relatively. A a component, a system that we're integrating into a maybe an existing vehicle platform. So then you're really focusing on what are the what are the cascaded requirements from vehicles perspective performance wise for the transmission, ensuring that the transmission delivers that and interfaces correctly with the other vehicle systems are.
Where do you see let's say, model? It's just again, systems engineer, not necessarily model based, but I think we all know that's where it's going to or continues to push towards. But what do you see systems engineering in 3 to 5 years? You see changes. Do you just see more of a deployment of it across even more fields and areas in the mobility space? Or do you see it become even more, let's say, digitized with much more more digital features? Digital twins coming in. I coming in. I don't know.
What do you see it in three and five or two, five years. Yeah. I mean, I think the tools that are being used, some of the existing tools are not maybe the easiest to get in and use. I think there's a lot of the tool developers are working to make them more user friendly. I would say, and easy to get into and add additional features and functionality and the ability to connect those model based tools with existing requirements tools, simulation tools as well.
So I think there's there's certainly an improvement in the tools themselves. And therefore, you know, the adoption of the tools. I mean, I kind of always think backed from a from a software perspective. You know, many years ago we started writing in assembler and then we kind of moved up to kind of see. And then from that we moved to sort of, you know, simulate and more graphical kind of that.
And there is something I'd say from a controls perspective, I think more of a move to be able to even be starting to really define your software requirements within the model based environment and actually be able to have tools that will sort of automatically or semi automatically bring that down into actually being able to develop code and implement code. I think I think that's potentially an interesting, interesting area.
Okay. How do you see systems engineering as it relates to, let's say, platooning and heavy duty trucks? Do we see it as there's needs to both trucks or all trucks, even with cars, let's say that come in as well, maybe part of the platoon. Do they all have their own systems engineering? And then those the overall systems of systems or how we start to be looked at? Yeah, I think that's a really important question.
I think we have to be developing standards so that we are all, you know, affecting the vehicle, needs to provide data, backup in into the cloud that can then be used in some way through some intermediate, I guess by the other vehicles as well. But I think standards and, you know, need to be, you know, adopted by people to be able to. Yeah. To to implement that. I mean it's yeah.
Yeah. If you think about the challenges we have when the mobility space passenger vehicles once this stay for a moment but I think even off road military or heavy duty trucks there's more and more technology, let's say, crammed into the vehicle, the mobility device. How important is systems engineering in this quest to make these pieces at the end of the day work to the benefit of the user, right. The driver, the passenger.
Otherwise, you have a conglomerate of different technologies, but they don't really gel together and really work together on the user experience may be disappointing. So how much how important is systems engineering versus maybe, let's say user experience engineering? Yeah. No, I think it's absolutely key.
I think, again, the the the aim of systems engineering really is to develop a system that's almost, you know, greater than the sum of its parts, those parts on their own, unless there's, you know, coordination and a cascading of of requirements of interfaces down to all those systems and components, you just end up with a, I guess, a group of bunch of components that kind of do what they're supposed to do, but not in an efficient and sort of most optimal way, cohesive way.
And so as far as the user experience, I mean, that's a key input as well to that systems approach. I think we have to. And when we do on the on the side, one of the key things we're looking for in input into our system development is if we're developing a system is, you know, what is the user experience that's baked in from from the very beginning. Yeah. How is the, how is this going to be used. What, what are the use cases for this feature.
You know, how will, how will this what will this feature experience as far as what the user wants from it and the environment it's going to be in as well. And that really needs to be very much understood as we develop these features and system. So it's always the end user ready to the customer that has to be kept in mind. And that's that's who in the end we're delivering to. Right. So everybody talks about the software defined vehicle, right?
Obviously, systems engineering is a key piece to allow this to happen. But let's say for a moment, there's issues in the field and we can use over-the-air updates to address the software. Let's assume we can fix it with software. Address it with software. How critical is the systems engineering approach that needs to be happening before that to really allow to do this? And how do you guys look at this? Okay, this could be a potential in the future. Mm hmm. How do we address this? Right.
Because it's not necessarily this is how ultimately the whole system, the vehicle, heavy duty truck, off road equipment, passenger vehicles is functioning or has to function. But how do you, in your approach with systems engineering, try and foresee what do you need to do in the future in case there's issues that you can address with a software over the air update versus recalling vehicles or having everybody go back to the dealership? Absolutely.
I mean, again, I think that that certainly is a you know, that's a requirement that has to get fed in from the very beginning, from the top, you know, this vehicle, this system and what level we're working at needs to have the ability to support over the air updates. Now, that also means that you, you know, critically need to be bringing in and considering the cyber security aspects as well, because obviously that that's key. If we're if we're starting to, you know, remotely update software.
So all those things have to be considered and have to be a key part of all of the requirements that we're defining at the beginning of, say, a vehicle program or a subsystem program. And then it's really making sure that those those requirements for cybersecurity for over over-the-air update, functional safety are are correctly cascaded down into to the components the systems that need to then deliver that that functionality.
And if it's across multiple components, they obviously need to do that in a in a very synchronized and aligned way. So. Okay. Thank you, Andy. Any last thoughts from your end from systems engineering that we maybe didn't catch here? That's important in your mind? I mean, I just I guess sort of summing up, I think, you know, systems engineering has been a key discipline, I would say, for for certainly for software and controls for many years.
Now, as we move towards more and more complex and connected systems as electric vehicle electric powertrains, hybrid powertrains, you cannot develop an efficient, robust system without a systems engineering approach. Okay. Thanks, Andy. Very insightful. Appreciate. Thanks, everyone, for tuning in until next time. Thanks for listening to Reimagine Mobility Podcast. If you like the. Episode, please subscribe and tell a friend.