Automotive systems: software and architecture – The Future Car on E/E Systems – ep. 4 Transcript
In our fourth episode of the Automotive E/E Future Car podcast series we discuss the evolution of vehicle architectures and the challenges of bringing them to life.
We are privileged again to speak with our experts, Doug Burcicki, Automotive Market Director for the IES team at Siemens, and Dan Scott, Marketing Director for Integrated Electrical Systems at Siemens Digital Industries Software. In this episode of the Automotive E/E series we breakdown some of the challenges to producing new automotive designs. You will hear how companies are changing their product development priorities and methodologies to adapt to current and future market demands and the role of E/E systems and new architectures in the complex automotive industry landscape. We hope you enjoy it!
Check out the transcript below or listen to the audio podcast.
Read the transcript:
Conor Peick: Welcome back to the Future Car podcast from Siemens Digital Industries Software. I am Conor Peick. Over the last three episodes of our series focusing on E/E systems, we have been busy examining all the major trends affecting automotive E/E systems development with our experts Doug Burcicki and Dan Scott. Today, we pivot that discussion to begin talking about what the future is going to look like. How are E/E architectures, and vehicles for that matter, going to evolve? What new challenges will the vehicles of tomorrow introduce? And how will companies transform to meet new challenges? All this and more coming right up.
So first off, we want to focus a little more on what the future is going to hold for automotive and vehicle development. The first question, and the very broad question is, why do companies need to develop vehicles of the future?
Doug Burcicki: Obviously, there’s a lot there that they need. First, you need a skilled workforce, people, subject matter experts, people that understand the full context of the design, and what you’re trying to achieve. It starts with high-level vehicle requirements. But those must be pulled together by people at the end of the day, using tools to follow a process. You hear buzzwords these days: digital twin, digital thread, digital product and digital representation. The fact is that you need people. If you’re going to be a successful organization going forward you need to leverage a common data set, and that’s the backbone of a digital twin. It is a common data set from the beginning of your process through the end of your process, used by all the individuals that touch that information throughout the development lifecycle. I think that’s probably the biggest challenge for companies these days, because as we’ve talked about, we have partitioned silos and each of those silos within an organization have their own process and tools, and those may not necessarily be compatible with each other. And that results in loss of data or data validity, adding time and error because people must reenter or recreate data. So, I think that’s one area that all companies must focus on moving forward if they’re going to be successful based on the complexity and the size of the data sets that they have to manage.
Dan Scott: Yes, we need a skilled workforce and engineers who have the relevant skills at the relevant time. And I think one of the things that’s interesting about this is the pace of change, which everyone can see has been accelerating, and this shift that we’ve talked about in previous episodes from a more traditional mechanical skills to software and electronics. But I guess one of the things this goes in parallel with is the pace of change. So, we need skilled engineers and tools. So, if engineers are going to be potentially shifting disciplines a bit more, or even just moving into slightly adjacent things from where they were originally trained, I think this type of tool usability, the easiness to pick up, and be able to embed the process knowledge or company IP, or what have you, and the tools. These are tools which augment and help engineers be creative and innovative by playing a supporting role. There is a leverage effect in terms of the innovation and the stuff that engineers can create. So, yes, that was just one thought that sparked when you were talking about the skilled engineers bit as well.
Doug Burcicki: I think you’re right. We see it today. And we talked in a prior podcast about many of the OEMs going through organizational changes, because they’re putting a greater emphasis on software. So, that’s resultant of this shift is more content and vehicle differentiation being driven by software. That’s not a skill set. They traditionally retained in high numbers, being historically mechanical or electromechanical based organizations or engineering skills that we’re delivering most of the vehicle content – that is changing. And we also know that the workforce is aging and you’re seeing a shift of people with 20-30 years or more experience retiring. There is not necessarily a structured way of retaining that knowledgebase. And these companies don’t want to go out and hire someone who’s just as skilled in an area that they need less expertise in; therefore, they want to focus on the areas where they are weakest. So, they want to retain that knowledge. They want to retain the ability to design these mechanical or electromechanical parts or implement these systems without having to hire experts.
And a way to do that is retaining the knowledge that you have in tools if you can so that you can then automate that process. And in some cases, they are not able to backfill that spot. They can use tools to process data Instead of people to reenter data for no value-add activities. And like you said, let them focus on innovation – how to optimize and improve whatever facet of the design that they’re working on. It is becoming even more critical given where we are in post-COVID because we know the financial impact and repercussions are far from over. And we’ve already seen OEMs, and in some cases tier one and tier two suppliers go bankrupt. And in other cases, laying off significant parts of their workforce. And what they’ve done in many cases is they’ve laid off their more expensive aspects of their workforce, or areas that they feel are going to be more obsolete in the future. So, they’re going to retire with younger, less experienced engineers in areas where they are not as strong right now, like software, for example, or validation and simulation areas where they’re focused on trying to reduce their development life cycles, as well as reduce their expenditure and reliance on the number of resources that they need to realize these designs.
Dan Scott: Yes, you see engineers shifting in this same way, and needing to have this kind of continual learning mentality for companies like ours that provide those tools. One of the key things is learning support, whether that’s online courses, on-demand training or face to face training. These types of training provide a way for companies like ours to support engineers and companies to get up to pace quickly, or learn new aspects of tools or processes. It’s a more holistic offering, isn’t it? It’s not just, “Here’s some software, go enjoy.” But it’s kind of a big picture to really help them equip engineers to do what they need to do.
Doug Burcicki: To that point, no implementation is the same. We have the same software that we provide to hundreds of customers around the world, and they all use it differently. And some of them need guidance or help in figuring out the best way to use it based on what their process or constraints. So, yes, that’s a very real aspect to the environment and the market today. And it’s probably even more evident because of many working remotely from home for the most part over the last six months, and for the foreseeable future. So, having people quickly learn and adapt to new tools and processes from the comfort of their home would have been nice to have just a year ago, but now it’s becoming essential for effective implementation of these tools and processes.
Conor Peick: Kind of leading on from this discussion, I want to ask you guys the role that you think company culture or corporate culture can play in the adoption of essential tools and learning.
Doug Burcicki: I think it’s probably one of the single largest factors and whether you’re successful, or how long it takes you to achieve success once you go through any process transformation. Certain companies are very adept at changing and pivoting and refining their approach based on what’s going on around them, what’s working and what’s not. And others have, you know, a longer history, so they don’t see a need to change: if it’s not broke, don’t fix it. They’re less incentivized because things have worked for years. But they’re not maybe as reactive to what’s going on around them right now. So, I think that that, in short, it is one of the single biggest challenges to overcome. But again, it goes hand in hand with the scope of your project. It is easy to implement projects and process improvement using a particular engineering team or a portion of an engineering team. It’s when you’re across the full enterprise, right? It’s when you start talking about affecting a process that impacts a guy who’s responsible for the architecture definition, as well as the guy who’s responsible for the networking requirements that come as an output of that definition. And then the resultant software structure that’s resulting from the ECU partitioning and feature allocation. So, they’re all intertwined, but we’re not necessarily making decisions with all those groups involved at the same time based on what’s best for the enterprise.
Dan Scott: The culture is an interesting one, linking back to what we were just talking about with regards to the engineers, particularly for things like recruitment and retention of employees – getting and keeping the right skills into the business. The culture has such a massive impact on that in terms of a generation’s stereotypical younger people. Younger generations coming through have different expectations of what work should look like, including the environment of work. And it’s less about presenteeism – being physically in the office and showing your face clocking in, clocking out and doing your hours – but more about flexibility. It is much more about being able to express themselves and be creative, and I’m thinking particularly around engineering and those sorts of skill sets. But I think the broader company vision and company focus has a big impact on people’s decisions increasingly well. Whereas, historically, people were less worried about that. It was less of a consideration. I think that’s changing quite a bit. We have companies today where the culture has a big part in that. So, in terms of their adaptability: can they adapt to change? I think that’s such a massive thing. It’s like that innovator’s dilemma that Clayton Christensen talks about, where the incumbents get so fixed on keeping their cash cow going that they’re unable to break out of that and try something new and take risks and dare to fail, those sorts of things. So, I think it’s a continual challenge for companies. Because culture is all about the people, isn’t it? And the priority is that the company is set. So, I think it’s a massive deal.
Conor Peick: It’s like we talked about last time with the example of Tesla coming along, and kind of eating the lunch of the big, traditional OEMs in regard to electric vehicles, where they maybe hadn’t recognized the appetite for such a product. And this smaller company that didn’t have such a long tradition was able to come along and demonstrate quite a large appetite for it. And of course, they needed a compelling product to make that work but I certainly think there’s an aspect of the larger companies being a little stuck in their ways, perhaps.
Dan Scott: we’re all certainly being perceived that way, I guess. I’ve worked for a variety of different companies from startups to tier ones, to big OEMs, to what have you, and consultancy firms, and what I found interesting, is looking at them from the outside, it’s easy to think that it’s a stereotype: big OEM, and traditional OEMs are quite stuck in their ways. There are aspects of some companies that absolutely like that. But balanced in amongst that, you have pockets of creative and forward-looking people trying to make change happen. It’s quite an interesting time because big OEMs know they have to change, they know that the traditional business models and traditional products are not going to be the future. And so, it’s like, “Well, what now? When do we change? We’ve got these products that are making us money. At what point do we make that shift?” And this, you know, for them, unlike startups, or differently to startups, there’s a big risk factor for them in terms of when they press go on that. So, I think that’s a big challenge and a hard one for them to manage.
Conor Peick: Yes, that’s a great perspective, and thank you for bringing that up. I hadn’t considered the difference between perception and reality, which can frequently be quite large. But maybe next we can move along to the future of EE systems and where we see those progressing based on what’s going on today.
Doug Burcicki: I want to back up and say it may be more of a struggle in the cultural aspect in some of the legacy companies. At the end of the day, those companies are going to come from the top down, having structures and organizations that have existed for decades in many cases. And like I said, things have been done a certain way, with their specifications and process documentation that has been followed for years. And people are very averse to changing those things because they’ve proven reliable and repeatable. But they’re not sufficient to keep up with the pace of the modern technologies and the development cycles – the cycle of consumer electronics that are driving content in the vehicles. And we talk a lot about automotive and transportation, but the same discussion can be held in other industries, like heavy equipment and agricultural equipment. There is a tremendous amount of autonomous technologies being applied to those fields. And they’re going through the same struggles that the traditional automotive companies are, but they’re handling things in a little different fashion. It’s being driven from the top down because the people who are doing the day-to-day jobs don’t want to change. I’m not going to say it is across the board, because there’s always pockets of people pushing for improvement in process, enhancement and just bettering what it is that they do and how they deliver it. And they’ll never stop.
But for an organization to change across the board, or to pursue things from a different perspective, it must come from the top down. You know, it’s why you see there are leaders out there that are trying to transform their organizations and be successful to different or various levels of degrees. But then you can clearly see other organizations that are not, because maybe that’s their strategy, to not be a tech or an innovation leader, but to eventually turn into a contract manufacturer or focus on system integration. There are different business models out there that can be successful. Part of my observation is it’s not just a lack of willingness, as some of these companies are reinventing themselves in ways that may not be aligned with being tech powerhouses or staying at the forefront of technology. And that’s just part of the evolution.
Dan Scott: Yes, that is interesting, Doug, and it reminds me of something I was thinking about recently. I would be interested in your thoughts on this as well. We are going through this kind of revert colonization or most of the supply chain where, for example, somebody like Tesla, historically would not have been designing its own ICs, or getting down into the real depths of the electronics; they would be managing suppliers who did that for them. And one thing I was wondering about is, there is a that’s kind of happening and bringing a lot more of embedded software in-house where traditionally that would have been specked out to suppliers to provide. So, one thing I was wondering was, do you think that’s kind of like a long term trend that verticalization will continue? Or is this actually just like a natural cycle of manufacturers developing new technology, whether it was automated transmissions or engine controls, doing much of that work in-house, so they then understand in detail what’s required and what that means before they’re then comfortable to pass that out to a supplier and manage them, understanding what they’re delivering and drive them to do quality cost. So, I’m just wondering what your thoughts are on that? Do you think we’re just at the start of a cycle of that and in five years’ time, or seven, it would be back to tier ones doing much of their core autonomous electrification technology? Or do you think it’s less of a wider trend of having more verticalized organizations or OEMs?
Doug Burcicki: It’s a good question. I think you’re going to see a combination of everything. There are OEMs, historically, for content that has a significant impact on their cost structure or vehicle performance. If they didn’t do that in-house, they initially did it, so they understood it inside and out and could maximize the purchase if they outsourced it. This is a little different in the sense that, first off, the embedded software piece or the application software piece, as you said, is becoming a much greater aspect of the cost structure of the vehicle. Some estimates have it as high as 30 to 40 percent, currently, with projections of that being half of the development cost of an automobile by 2030. So, that reason alone is a motivator for an OEM to bring it in-house. There’s no OEM in the world who want to outsource half of their product development. But the other aspect is more about IP and differentiation. Everyone can have an autopilot type of function, but they’re all doing it differently. There are different technologies. There are different strategies regarding your sensor arrays. There are different approaches through the distribution of your ECUs and how you perform your sensor fusion. Every OEM has a different approach unless they’re buying a pre-validated subsystem from a system integrator, someone like a Waymo, or an Uber, that’s what they’re aspiring to be as a subsystem provider of autonomous functionality. So, you could do it either way: you could procure it externally if you don’t have the capability and don’t want to invest in it internally. But you’re buying something that someone else has. So, there’s no differentiation, but it’s cheaper cost potentially. So, some OEMs may look at that as their business model. Others, obviously, like Tesla took a much different approach.
And they went so far as to say that the silicon is part of the foundation of their IP and their vehicle performance. And it’s the basis of their vehicle architecture, and how they approach their entire autonomous architecture. So, they took a different approach, didn’t want to spec it and outsource it. And I think that that’s the first step in what’s been referred to as the decoupling of software and hardware. We have talked about development cycles and the challenges of the OEMs. Part of that is developing the hardware and the software in parallel because hardware clearly takes much longer than the software cycle supporting the software that’s running on it. And that software is what’s in a large part providing the feature. So, that’s a challenge for the OEM. But now you take that to the next step where they must source that business to a supplier. And what they’re trying to do is get to the point where they can develop a hardware platform and commoditize it, have it supplied by two, three, or four suppliers who they leverage against each other. And they own all the software, any IP that differentiates the feature, the vehicle itself, the brand. And that way, no one cares about the hardware, much like phones have become, to a lesser extent because there’s still the design and the aspect that you hold in your hand. But from a consumer perspective, when you’re driving a car, you don’t care what tier-one supplier provided any module on that vehicle. What you care about is the functionality and the feature that’s running on it. So, I see that as two different strategies that are both currently being deployed right now.
Dan Scott: That is an interesting analogy in terms of the Apple approach where they own the whole ecosystem, the software, the hardware, the distribution channel, and everything about it, versus an Android system, or even in laptops like PC or Windows world where it’s like, “We’ll focus on the software.” And then traditionally, the hardware, it will work on several different types of hardware, but that’s not our specialty. I think that’s interesting to think about it in that kind of way. Each organization is going to have to take a good, long, hard look at itself and work out where it can add the most value, and what kind of key area they can differentiate to carve a niche out and make some profit.
Doug Burcicki: As we mentioned it in the last podcast, you have a lot of tier-one companies out there right now that focus on hardware and software, and they provide a fully validated module based on a set of requirements from an OEM, and it’s essentially a black box. The OEM doesn’t necessarily care about the hardware and the software stacks in the box, they just want to make sure it meets the requirements. And now you’re getting to a point where the OEMs are specking more of that software, and in some cases, writing it on their own, and they’re only specking the hardware. And that’s not a good value proposition for a tier-one supplier to be in, it’s just providing hardware because then you’re just a commodity supplier. So, they’re trying to figure out how to provide more value to the OEMs, based on their various business models, maybe they want to move upstream and do more system architecture definition for the OEM or with the OEM or maybe they focus on certain features or functionality. They focus on being the best software provider for algorithms associated with charge coupling systems or battery management systems, whatever the case is, you focus on a certain area that’s in demand, or there’s a need for them and try to be the best in it. So again, there’s multiple strategies in play. And I’ve seen evidence of all of them. It’s just a matter of time to see which ones pan out the best.
Conor Peick: How do these trends that we’ve been discussing affect the EE architecture and the development of EE systems?
Doug Burcicki: There’s a lot of things we talked about. As far as EE architecture, it’s evident that if you’re not already actively developing a new architecture for your vehicles, you will be, very shortly, and you’re probably behind the curve if you haven’t started yet. Essentially, there’s a race and whether you’re focused on EVs, AVs, both or just being competitive in the marketplace at scale, you’re going through an architecture transformation. And you’re probably going to be going through another one in another five years or so, as we migrate from these distributed architectures of today to a more zonal architecture, and then, potentially even centralized architectures. But if you think about it, in EV, for example, it lends itself to a zonal architecture, because each wheel is its own motor and you can easily replicate and provide redundancy for certain features and functionality. It’s a natural evolution based on opportunities that are presented through the technology such as EV power trains that allow for this type of innovation, essentially to occur that you couldn’t do with an internal combustion engine architected vehicle just because of the performance design and packaging parameters.
So, the whole way the vehicles are being approached is changing. Essentially, there’s not a standard template for developing a vehicle anymore. If you look at some of the concepts that have come out in the last couple of years. I mean, you see everything from a box on wheels to some of the sexiest performance cars I’ve seen designed in decades. So, I talked about it the other day, there’s people that buy cars for features and content, and there’s people that buy cars for design and styling and performance. And what I really like about the EVEs is it’s a blend of both, I mean, you really can have the state-of-the-art feature and functionality. And those cars are just fun to drive. And the packaging freedom that designers have is second to none. So, there’s clearly a huge emphasis on EE architecture, redevelopment, and if you get it wrong, it can be detrimental to your business. If you get it right, you can be highly profitable. So, everyone is aware of it, all the OEMs are aware of it and are focused on it. They’re all trying to blur those boundaries as we’ve talked about. It’s essential for them to realize a holistic design. I think that we’ve talked a lot about complexity and the sheer number of options and design configurations that have to be taken into account. The companies that embrace that, and make that a competitive advantage, will succeed because they can differentiate themselves. Most companies struggle with complexity. So, I think that’s a big thing going forward. Also, we talked about the cultural aspect, and it really boils down to being willing and able to pivot and change and evolve based on the environment around you, whether it’s regulatory, market-driven from the consumer behavior, or technologies that are entering your space that allow you to go in different directions. So, I think those are all things that are either impacting the OEMs in their architectures or they’re doing or taking into consideration as they address them.
Dan Scott: One of the things I was thinking about, Doug, just off something you were saying just before about the decoupling of hardware and software was necessity; therefore, all the likelihood increases of things like standards, autos are where you’re kind of consciously trying to decouple those and create an interface where to write your software in a way that it can be reused across multiple platforms, ECUs, or what have you. And I wonder whether we’ll see an increase in adoption of standards like that, in specific areas, increase reusability and manage that complexity, which is exploding. But then the other thing I was thinking about was around virtual validation and verification, where you’re going to be able to verify and validate software ahead of having the physical hardware available, because at the moment you take that software and perform model-in-the-loop or software-in-the-loop. But it’s against relatively unrepresentative executing software, and against models.
So, you really must wait until you get hardware properly available, which can be quite a long way down the development cycle. And to kind of ramp up and accelerate that development cycle, and one of the things I think we’ll see more of is the virtualization of those ECUs, being able to replicate them to quite a detailed level. The actual microprocessor – will be kind of flashing this software onto, at a sufficient level, to give it a much higher level of robustness when you first get into some hardware, and you’re putting software into it. So, you have already higher confidence levels. And I think one of the things we’re going to be looking at is a real acceleration of those technologies. And that happens across multiple areas, whether you’re looking, doing more finite element analysis, or more fluid simulation, or whatever it is. But again, that’s something that must increase. And I know, we’ve all heard the quotes from Toyota of how many millions you’re going to need to drive in order to properly validate a vehicle. So inevitably, that’s going to drive that. But even outside of autonomous, I think there’s still a shift towards that as well.
Doug Burcicki: You’re spot on. I think that virtual simulation validation is a rapidly growing area. I’ve seen in several studies where it’s been identified by Executive Engineering Leadership as an area of high investment and high prioritization. And it’s multiple reasons. I mean, there’s clearly the timing, the improvement in your development activities. There’s the ability to root out those bad design issues or potential failures early on in any development process. And as any engineer knows that earlier you find those issues, the less costly they are to fix as opposed to later in the program. One of the other things though is just the overall speed to market and cost in the sense that right now the traditional vehicle development cycle has you go through multiple mule or prototype build phases, each of which must lean vehicle-specific deliverables. These are pre-production builds; they’re not ready to be sold out there but they’re essentially production vehicles as intended to be built production vehicles and these costs millions of dollars for any OEM to go through those phases. And if you could eliminate any aspect of those, or ideally one entire cycle of those development phases, you’re saving yourselves tens of millions of dollars potentially, as well as months of development and tooling and dollar validation associated with it. I’m not saying by any means you skip any aspect of your process but if you can enter a phase of development with a higher level of design confidence based on simulated or virtualized design data that you started with, you’re going to be better off.
Yeah, I agree with you, Dan. And it leads right back into the digital threat; you can’t do the virtual validation and simulation unless you’re leveraging the exact same design data that’s reflected in a real-world application or use-case. So, it’s a perfect example of why you need a digital thread to be successful. And then, even shorter-term, low-hanging fruit is just pure data continuity. If you look at a development lifecycle, there’s a series of requirements that every OEM starts with vehicle design with, they could be legacy requirements from a prior vehicle. They could be government requirements. They could be requirements coming in from a partner if they’re involved in a JV or a co-development, whatever the case is, I need to homologate those and generate their preferred architecture because of this combination of requirements. And then that feeds downstream. Internally, they hand off that data to development teams to start developing the network, their software architectures, and structures. They hand off electrical connectivity data to a supply base to develop a set of wire harnesses. Various suppliers involved throughout that whole process, when they’re done, that data must come back to the OEM so it can be assimilated into service documentation. So dealerships and field technicians can service these vehicles over their life in the field. And again, if you must re-enter or recreate that data, no service technicians are going to be able to stay on top of the status of any vehicle he’s looking at. Now, if you think about the future landscape, less and less, you’re going to have car companies that have a series or network of dealerships spread around the country or the world to take care of your vehicle. More and more, you’re going to see companies move to a Rivian or a Tesla type of model, or they don’t have a dealership. And if you have a problem or an issue with your vehicle, a technician comes to your house and pulls up in your driveway. But you got to keep in mind what we talked about with over-the-air updates, you could have had dozens of software updates since you purchased that vehicle. You may have added features and functionality since you purchased that vehicle, how does that technician know the level of software and feature content that you have unless he’s able to access the digital content that is contained by your vehicle specific to the VIN, so the digital thread story that enables that simulation and validation, that’s like the middle of the process, that digital thread has to start earlier and it should extend all the way through the life cycle of the vehicle.
Dan Scott: That ties back again, doesn’t it? Into this of virtual verification of — even in the design process of kind of closing the loop on stuff where you’ve got vehicles out in service, which now just running around in real-world usage conditions, where you’re able to get actual vehicle data from them. So, not just, you know, nowadays, someone plugs in a locker or a diagnostic tool and can download some data but we got these telematics systems where you can get real-time data from vehicles, you can actually use that for performance analysis of the fleet where you can use it for understanding how your motor is operating and look at optimizing software back at the OEM to push out a new update over-the-air, as well as to feed into your next vehicle program where you’ve got actual real-world data of how people are driving nowadays and how people are using the vehicles. So, I think that side of things as well as being able to push that data back from actual vehicles back into the development process, which we’ve not really had in a usable form ever before, I think. Well, we should have quite a big impact on that team.
The disruption being experienced by the automotive industry is well documented, including on this podcast. Amid this disruption, industry participants are busy working out the best ways in which they can create value, innovate, and position themselves at the forefront of the industry. For OEMs, a major focus is the development of brand new E/E and software architectures designed to scale in support of advanced features and functionalities. Meanwhile, suppliers are hoping to establish themselves as experts on delivering complex vehicle features, such as ADAS and self-driving. Throughout the industry, the result is a growing emphasis on E/E systems and software, demanding new product development methods that blur the boundaries between vehicle domains. Our sincerest thanks for listening, we hope you enjoyed the episode.
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
