Congratulations, Sandy and team, on opening this very important topic. In software-defined cars, a lot of current and future functionality (and value-add) is in software. So software architectures, software development/verification-validation methodologies, software maintenance and upgrade strategies, cost metrics as applied to both development and maintenance, metrics on the performance of safety-critical software systems, and so forth become very important. Munro & Associates’ ability to do analysis of automotive software systems will become more important than its ability to do analysis of hardware systems. Perhaps it already is. The percentage of software functionality in a typical EV today greatly exceeds the percentage of such a vehicle’s hardware functionality. This has been true in the aircraft industry for decades. Software is and will be at the heart of car companies’ value proposition going forward, and Munro & Associates needs to increase its capability to meet this new reality. These seem to be exciting times for you and your team. I’m looking forward to hearing more about all this in the future.
Congratulations; Sandy and the A-Team at Munro. This is the sleeping giant in the Automotive closet. My time at Magna, Ford and GM saw many...opportunities for improvement. Usually shot down by Finance or old-school management. It's high time for new 21st Century standards and the Tesla approach of true overall modular product systems thinking 🤔. Plus; get Rid of all those non upgradeable micro processor modules.
Well, from a consumer view one problem might well be that they CAN (& DO) easily make changes to it. Basically, the consumer is being pushed out of the loop. He can't decide whether a particular upgrade is function in his particular case. This is accepted reality with Tesla. So far as I know, the "software" upgrades on other vehicles requires a visit to a dealer. Another area where the consumers are out of the loop is in modern farm machinery. Farmers only have a "take it or leave it" approach to how their close to one million dollar machines operate. What is comes down to is "Right to Repair."
@@GilmerJohn Kia/ Hyundai/ Genesis have last 2 years started offering firmware/ software updates for clients cars. This can be done from home & followed through simple instructions. Until now, they deliver updates twice yearly.
*I saw 40 minutes!, But as a software engineer since the 70, and if you cut me, I bleed zeros and ones, I couldn't avoid this video no matter what. And, that 40 minutes went fast! Thanks for doing this video Sandy.* *Super excellent conversation.*
Gee, I write embedded code. Yes, I use the C command set, but I compile under C++. There is nothing wrong with this combo. The sensor data is appropriate to C data structures and the various comms protocols between devices. If you want to call a C++ library, have at it. No, we don't need a whole new paradigm. Only where human interfaces are concerned do we need all the kewl stuff. Most of the car compute is consumed in sensor, radar, and image processing for uses other than human consumption.
@@roberth5435 Whilst the current technology paradigm works with a narrow view, I think you missed the whole conversation. I recommend trying some Hopi Candles and have another go at hearing what was said. C and C++ developers generally are almost as rare as honest politicians. So while you are in the vulnerable position of being perfectly equipped for the old paradigm, there is probably more than enough work to keep you going and you can comfortably ignore the new paradigm. _"Progress happens not because people change their minds, but because they die"_ One of the huge differences between the days Sandy talked about when C was they latest and greatest and today is that compute is a fraction of a fraction of a cost. Do you know how much compute is in your wallet? There is more compute on the chip on your credit card than the Apollo moon rockets. So, choosing a language based on frugal resource usage and speed is in many cases not the main selector.
@@Sidowse cost of vehicle like 40k you mentioned isn't static. as a breakthrough tech the EV needed to flex its superiority at cost. so hypercar power with in many cases better range than comparable hypercars at a fraction $$. light vehicle with good range will be really cheap. but this barely matters compared to cost per mile reduction. switching takes time and certainly sticker shock but Solar EV combo will be game changer even before autonomy. companies that do this will have a honeymoon period of better margins before competition makes them honest again and real cost reduction gets passed on. .02 😉
@@Sidowse You, me an Elon agree that cars are too complicated and heavy. I doubt that regulators nor manufacturers would want consumers updating software, even if they can demonstrate competence. They do likely use opensource software in the mix, but behind a locked door. There are people who can hack the cars, but as far as updating software, on a car that is used i public would be insanity if you were doing it flying blind and unable to run a tougher set of tests over it. For smaller vehicles, i expect you can build your own and have the option at least to use your own software, but again without a team with a good understanding of the system, I would leave critical things alone. When a firm goes bust there is usually a fairly complete parts inventory that someone picks up or gets left with. For example the DeLorean has a company who has all the original parts, still boxed and who make parts that are no longer available. Dustin's last SmarterEverDay view was about a guy who repairs tractors that are up to 80years old, making parts as needed. I with you on the small city three-wheeler with two seats, but with Arcimoto filing for bankruptcy, which is sad but not a shock, I'll have to sick to two wheeled electric bike + two wheeled trailer. E-bikes will be licenced for public use, regulation is currently in catch up mode, ebikes are essentially motor bikes and deserve safety considerations and restrictions in public, like anything else in a common law jurisdiction, that could cause loss or harm. My bike is currently not road legal, but for me the power is usually for towing, not toeing it.
Hats off to the videographer of this one, shooting under the chin, without a monopod/tripod, and continuously changing the lighting was something I'd never have thought to do!
I have soooo enjoyed this coversation. People think they got Teslas figured out but ohhh brother, the closer they think they come, the clearer they see how Tesla is ahead...
Yup. Other automakers unveil their new ev and basically it’s all about what’s on the surface. Thats followed by so called RUclips and other reviewers gushing over them one by one as they come out 🤣
@@Johnny2Feathers Just like the automotive stock analysts keep saying "Tesla models are outdated. Tesla needs a refresh to capture demand." Tesla responded by dropping prices by 20%, demand 12X overnight. Nobody is buying the Analysts picks that are edgy and new. Everyone is buying the "outdated" Teslas... lmao If it ain't broke, don't fix it.
Excellent discussion. As a almost 60 year career in software, I can assure these issues are not restricted to automobiles. More broadly speaking, it is an issue of data silos which in turn tie back to organizational structure. At one point as a newly minted DBA I worked for a retailer (no longer in business) where I tried to get their credit card operation, catalog department, and parts service departments to share their customer data. No luck! Each group thought only their data and needs trumped the thought of looking at a total customer picture. With a slight shift, I believe BMW management recently said they didn't think their cars should be Apple IPhones on wheels. At first glance, this seems to contradict your referencing BMW as being forward looking from a software view. Probably remnants of continued siloed thinking.
This is painful to watch. Android runs on Linux. The speaker seems to not be aware of this. He claims that BMW is moving away from Linux when they are adopting it. Also they have no idea about modern programming.
This has been a wonderful look into something you don't usually talk about. I appreciate Sandy Monroe more and more every time I watch one of his videos.Thank you very much.
It is interesting that Tesla is not using off-the-shelf software like SAP, but writes their own business management software. It makes sense to code your own solutions if you are also vertically integrated and have the capability to push the leading edge of development. Here, Tesla shows itself as much a software company as a hardware one. Additionally, Android does utilise the Linux kernel. For entertainment, Tesla has done something similar by adopting Steam in its latest S/X vehicles.
Tesla doesn't have business people. Engineers manage themselves. It is impossible for ford, gm, vw, etc to compete in any way because the companies are controlled by business people, not engineers. If any of them wants to survive, they need to write software similar to tesla which also includes tons of automated integration testing and fire all the business people. A company ran by business people is never going to fire themselves and the rest of the managers. Legacy auto cannot survive and will be replaced by new companies that have way less business people eating up their payrolls. Most of what legacy auto spends on payroll goes to dead weight, not engineers.
There are advantages and disadvantages of both solutions, there's no one right answer. For Tesla vertical integration is the obvious choice for many reasons. The main ones are that they have the resources to do it, and that the whole company operates very unconventionally.
Well Tesla is a software company that happens to sell cars. I think developing Autopilot and selling in the future is more important to them than creating good quality cars.
@@Bierkameel Well, even their execution of hardware is software inspired, so yes they are primarily a software company from that point of view. Also I'm very excited about the bot, as I think that the diverse requirements this will place on their AI development will give them an additional AI perspective which I believe will help them solve the real world driving AI even better.
Moving away from Linux to Android... umm, Android is basically Linux plus a touch-centric mobility-focused GUI (with lots of support APIs of course). So, it's not that tough of a transition for infotainment, all things considered.
Android is linux without having access to root. So you need all these silly APIs that limit what apps can do because the owner of the phone cannot manage permissions of apps. Google holds onto ownership of any phone that has android on it because only google has root access. This allows google to limit sideloaded apps so they cannot be much different than the apps in google's store. If you could easily sideload better apps, the google store would die off.
@@_PatrickO You can setup any Linux environment this way... By default actually a newly created user will not have root access. You will only be able to get that through for example giving that user the right to use sudo...
HW compatibility with Linux is much longer than android. My 6 year old CR-V has android "box/panel" which can't be upgraded with newer android thus seized. There are tv-sets which can't play Netflix due to old android versions. Not to forget couple year old mobiles which don't get security updates. Those don't support car for lifetime idea. Perhaps car for 5-7 years is supported.
@7:15 not only is every "hop" a latency issue, each step/hop usually includes at least one connector (usually 2 - one in and one out) - in addition to the device itself. ALL of these are additional points of potential failure. As much as Sandy hates (un)fasteners, I hate electrical connectors even more, and I'll be he does as well!
A few things to note: 1. There is some standardization in the auto industry such as AUTOSAR, UDS, OBD, etc, but a lot of the software is replicated across the ECUs. We have used common software from ETAS, Vector, Electrobit, etc to integrate software for various supplies and OEMs, but it is costly. 2. Just because C is old, doesn't mean its bad. Automotive systems require guaranteed operation, which means having extremely detailed control of your software. C allows that, along with having been tested over the many decades. Not to say other programming languages do not, but C has a lot of infrastructure around it in the automotive world, such as MISRA and ISO-26262 compliance.
Well, having over 20 years of experience with C and some other programming languages, I must point out, that when you want to start moving from heap of small ECUs to few large powerful boxes, C would become huge burden. And don't forget, as cyber security starts being more and more important in automotive (way too late in my opinion), securing C apps is just huge nightmare. I do like C and I'm still using it a lot for programming IoT devices, where you usually have some tiny power efficient MCU, but for most other purposes, there are much more effective options.
@@MiroslavMaiksnar I agree, there are disadvantages as you mentioned. One of the many advantages of C is its use in real-time systems. Because of this, I don't see a scenario where you can have something like your braking controller being written in anything other than C. If you look non-safety critical systems such as infotainment, I think you're right, C is not necessary.
@@embeddedone C is not only language suitable for real-time applications (it is just most traditional one). But in discussed microservices architecture you can easily combine different programming languages, so you can still use C for critical tasks. And as most ECUs currently use old 90nm or 45nm technologies, high level programming language on faster modern MCU will give you better latencies than C on old HW - modern compiled languages have very similar performance to C, you just need to have control over features like garbage collector (if present), so it don't kick in during critical sequences. Or use language like Rust which does not have dynamic garbage collector at all. Personally, I'd use C or C++, as I have long experience with them and wouldn't like to experiment on critical use cases, but it's not the only option these days.
Moving away from C will cause a big performance hit unless it is replaced with a similarly capable compiled language. Rust is probably the best option.
@@vrajeshkumar also, I don't think the memory management system is robust enough for embedded systems limited memory. So most development will be using unsafe rust
@@vrajeshkumar rust may make it to the main stream or it could become one of the hundreds of C killer languages that disappear, C is one of the few things that has survived more killers than Tesla
Great contents. Move forward with automotive coding. Unfortunately, we're stuck with millions of cars using the old standards and sometimes the dealers and techs and support personnel (manufacturer) with all the expensive diagnostic tools can't figure out what's wrong with the car. They make it so complex that instead of getting out of the hole, they keep on digging.
This is way above my paygrade. So this is hard? Complex, critical to advanced tech, and moving fast? That much I get. The rest.... glad there are guys like Sandy,Thomas, and Elon to bring it all together. Keep up the good work.
I'm sure Dan O'Dowd and Green Hills Software embedded automotive realtime OS will want to jump all over this, too, and deride Tesla FSD again while at it :) except.. they are exactly the same old "monolithic lockbox" type of system that they are complaining about, vs modern Android and other software platforms... maybe Dan will target Android Auto as "inherently unsafe and dangerous!" next ;)
Which is why Mr. Mueller was so keen to tout that BMW is moving away from linux. Sadly Mr. Mueller has his facts very wrong in claiming that a move to android is a move away from linux.
I have been a computer programmer for almost 30 years. I started off in C and have professionally worked in dozens of languages. Each language has it's strengths and weaknesses. C has been chosen for it it's small and fast code. It requires the developer to handle more of the error/memory checking. Which if not done right is very unsafe. Newer languages like C# manage errors/memory automatically. But it also has so much bloat. Newer developers don't understand how much bloat is behind each piece. C requires you to think. C# is going to require more space and faster processors than C. So it's a double edge sort. IMHO modular components with standard communication APIs and Secure C apis/libraries would do wonders.
@@Bora_H I love C, everyone once in a while I still write some c for fun. Learning C is a great basis to make you better in other languages. It gives you an idea on how things work behind the scenes of c# etc. I had one job writing software to merge a lottery ticket printing conveyor/ink jets all the way to the front end business. I used a raspberry pi to measure the distance travelled on a conveyor belt (through shaft drive sensors and calculations). I tested it beyond what it would ever be used. It would process 90k signals a second with the cpu at around 90-95%.
Exactly right, but more to the point, C is just another tool. You have to pick the right tool for the job. If your talking directly to hardware, C is probably a good choice, if you're building user interfaces, then probably not. You could do it, but there are other tools that are much better suited for the job.
@@RomanRomaniuk I agree, the question becomes how it is designed via hardware. If it is one system, the C with custom libraries to build the UI. If it is multiple with communications between the systems, then it makes sense to use the power of various languages.
Nice job Munro Live team. Not a sexy topic, but one that needs attention. This is the part of the automotive industry which many legacy builders have struggled with. I remember a couple of years ago Ford invested into a campus in the Silicone Valley and some did not understand what the point was. Not sure if the investment has paid off, but it showed someone at Ford knew software is important. The recent mess VW had with their software development program shows their leadership does not understand what to do. I know many old school piston heads hate the digital age and how it is now taking over the automotive world, but I do believe it will make the transportation experience better over all. The only thing that bugs me at the moment is the way so many are focused on subscription fees. I get, a business wants to know where their revenue will come from, but when they put heated steering wheel under subscription or remote car start under subscription, features that for decades you bought with your vehicle and got to use until the vehicle was scrapped, but now you have subscribe to those features, that sucks. I do not want to pay tens of thousands for a vehicle and then thousands each year just to keep some features we commonly have gotten over the past twenty years. Back to the point, glad to see software in the automotive industry getting some coverage. Software is crucial to vehicles now and will be more so in the future. I hope to see more software conversations on Munro Live.
Love it. Reminds me of the frustration I experienced when first confronted with the legacy PLC madness in highend industrial process automation. What a farce.
Thomas is a smart guy and surely his skills are needed in every, not only auto manufacturer, but a much wider field of business. Very interesting video.
I think the C and Linux criticism is baseless. C has evolved over the 40 years. Android is built on Linux. The real problem must be bad code. Everything else said was awesome!
Great interview. This was, although very geeky, the most informative video (from MunroLive) in ages. Thomas brilliantly laid out obvious solutions that could save companies and babies.
I love this. Process control in chemical and hydrocarbon processing have implemented distributed control systems where all process variables come into and out of central process computers such as Honeywell TDC, Fisher Provox, Yokogawa, Rosemont, etc. unbelievable that android software may run a car. Shire didn’t know that. Very,very interesting!
It seems that with CANBus and messaging, each part of the car can take care of itself and let the other interested parts of the car ask or request info or action. 1 ECU for each door for instance. 3 wires - power, data, ground. Make the car a local network. Each individual ECU OTA updateable, like an Arduino. -Seats -HVAC -Entertainment -Drive unit
Imagine the vehicle ECU as a web server. The displays are web pages. The user has endless customization possibilities. Like a 'glass cockpit' in an airplane. Beautiful skin packages available for download.
Sandy this was a great discussion. I kept thinking oh Tesla does this or Tesla does that. You can appreciate how far the Tesla Team are ahead in thinking. 🇨🇦
Such a relief to hear someone talk about software-defined who actually knows what it means. My interests are reliable auto braking, improve stability control, & AFFORDABLE full autonomous, most of the rest is toys.
What a brilliant discussion, there are so many points brought up by this video but if I can say something F1 has had a standard ECU for many years as well as other standard fit items, but engineers still Taylor to there own needs. The future is you will be to buy a app for a speciality off a specific team.
Sandy...it's easy to understand why C and the like. It's scalable. It can run on anything from a single CPU chip to a mainframe. With such a wide range it's a perfect match for that which Tesla might be doing. That's in a general sense, of course. I'm an old Unix coder (we used to call ourselves Systems Analysts) so consider the source.
The idea of having a "skin" or a user interface that you can download into the car is a great idea. We have been driving Fords with SYNC and my wife decided she wanted a Honda. The car is fantastic but she hates the user interface/controls/displays compared to our other cars.
Interesting dichotomy between the attitude to Tesla pulling in house, seat making, hvac making, 'parts' making, which is lauded, with the view of building a standard software stacks, across marque's. ;-)
The whole lines of code metric is going to become outmoded with machine learning, it doesn't exactly write like that. And more isn't always the wave of the future, an engineer who can replace 100 lines of code with a few did a great job.
By law, manufacturers have to provide repair parts for 10 years. They should be required to provide software updates for security and compatibility for at least 10 years too. Those updates (and any required programming software) should be freely available for any qualified person to install. All of those fancy screens look great until they don't work because the services are gone or incompatible when the car is only 5 years old.
A reason for breaking up functionality into multiple ECUs is that it is easier to characterize failure modes. Having a lot of applications running on powerful central processor makes characterizing what happens when one or more of the constituent applications fails difficult. Can a crashed satellite radio app make antilock braking quit working? What happens if a telematics app is hacked? How are software failures compartmentalized?; can it be done without disrupting time deterministic apps running on the central processor? The other thing to consider is the wiring. Running analog inputs to a central processor requires more noise shielded wire. Thee could be merit in employing limited function networked ECUs to handle conversion to and from analog at the points of acquisition or application.
It is theoretically possible to accomplish the same compartmentalization virtually in a single computer. Your point about signals is on the mark, but not sure whether it's really an issue. You don't need a full ECU to convert analog to digital and put the data on a bus. I don't think the presenters in the video are proposing that every sensor in the car wind up with its own wire going back to the main processor unit; that would be crazy and dramatically increase cost and potential failure modes. Now, will auto makers follow good security and reliability methodologies to make sure software components are properly compartmentalized as you rightly say needs to happen? That remains to be seen. I don't have a lot of confidence in their ability to do so, at least not without some government regulation providing strict guidelines for the kind of consolidation of software being envisioned in this video.
This, and CPU's are cheap as dirt. So why optimize by put infotainment and critical subsystems on the same hardware. I do not want the critical stuf and the non critical run of the same power supply or use the same data network. Although I don't think they have that in mind, but more something like consolidating software of the same criticality. And a graphical display written in c is far from perfect, so getting a more modern approach might be an improvement. Displays of all types of brands hang and crash these days, so change is good.
yes 100 million lines of code with no mistakes reminds me of playing blackjack in basic with 1100 lines of code.very good ideas are presented here and interesting instruction
Well, back when IBM was the "Be All, & End All" in computers, it was calculated that each and every "line" of code that's been debugged, etc., requires one man hour of effort. That means the code requires to 50k Man Years of coding effort. That's on the order of $5 billion$. Go ahead and make your own ASSumptions but "something ain't right" here.
IBM quietly buried their operating system mistakes by paying for their mistakes, back in the 1960’s mainframe day. They also fixed their mistakes usually within hours. Eventually, their operating systems worked correctly.
I worked with software for almost 20 years and for most people it is just an invisible thing that does something. The possibilities are almost unlimited but you have to know what you are doing. In a lot of industries they use software that is still from the 80's because its so old that most bugs are solved. And so they don't want to risk anything. You have to work with stuff that is older then you lol This video is so interesting, love hearing this stuff!
Sandy, This was a fabulous discussion of software used by the automotive industry. I have shared this video with software engineers in my church mens morning prayer group and an Intelligence engineer who is responsible for Risk Management training and evaluation.
Compliments for the excellent video! An important root of most problems mentioned in this video is 'enginering by catalogus' (as Elon calls it), so stitching 30 to 100 components (eg. HVAC, infotainment, motor-management) from different suppliers together by Canbus networks. I prefer to call that 'cut-and-paste cars'. We should learn all the dumbo's that there are two types of cars: 1. 'integrated cars' (Tesla and the Chinese brands) and 2. 'cut-and-paste cars' (the rest). So tell your Grandma!
Great discussion - I think this goes a long way in validating that the likes of GM, Ford etc are screwed - there is no way they can even get close to this, maintain it, evolve it and be competitive longer term…
This was painful to listen too! The complaints Sandy had about embedded based systems makes me think he has been out of the automotive development cycle too long! The C-programming language was developed in the 1970's for a UNIX based system, it really did not gain popularity in the automotive industry until the 1990's mainly because of the cost and complexity of the tools, and toolchain. Additionally, Google Android is based on a Linux root (open-source). Note, Android has limitations, and is not used for safety critical functions. I'm surprised they did not touch on "open-source" vs proprietary SW.
It got more painful towards the end when Mueller was really pushing his business venture by talking about 3rd party downloadable skins on safety critical systems. Is this a joke?
@@jamesvandamme7786 but what is the point? 95% of the software can't be downloaded and used by anyone except other car companies. It's not like people will be updating their own car sw or inviting 3rd parties to replace sw. Outside of the tuning space and occasional Android headunit hacks. But that's in the 5% realm
Having spent 30 years in the IT industry when someone tells me that a car has, on average, ten times more code than a massive commercial airliner my instinctive response is to question why the car maker would not scrap their system and start from scratch with a spec of what the system is supposed to do. And all those ECUs? Argh! Each has to have at least one comms connection, one sensor connection and one power connection; add the ECU itself and each ECU represents a minimum of four possible points of failure…. Madness.
Wow Thomas really knows his stuff and is extremely good at explaining complicated things. Thousands of Tesla fans would love to learn much more about how the software in a Tesla works!
And a lot of them would love to hack into it. Seems to me that if a Right to Repair law applies to every other electronic gismo, that it ought to extend to electronic autos.
Great interview guys. This is what WS is missing and what Legacy is struggling with with a behind the scenes as to why and how much IT MATTERS. Tesla is more than just a '"car company" and the definition of a car company now will be based on it's software as we valued engine specs and transmissions.
Yes, at first you write something that does the job. And then you start the optimization. You want that thing to run with the least written code possible.
IBM once famously berated Microsoft employees for their low count of KLOCs (thousand lines of code). I guess they would have been overjoyed to find 100 million lines of code in an automobile. To me it sounds absolutely nuts.
Such an important topic. Traditional Automakers are mired in outdated technology & software that takes years to update. They have got to adopt modern centralised computing on upto date hardware & software, otherwise they are going, the way of the dodo...
Being a gearhead, I watched all your teardown videos, but this video was like watching a great movie that you didn't want to end.
One of the most informative episodes I’ve seen recently from Sandy. I’d like to hear more about automotive Sw.
Congratulations, Sandy and team, on opening this very important topic. In software-defined cars, a lot of current and future functionality (and value-add) is in software. So software architectures, software development/verification-validation methodologies, software maintenance and upgrade strategies, cost metrics as applied to both development and maintenance, metrics on the performance of safety-critical software systems, and so forth become very important. Munro & Associates’ ability to do analysis of automotive software systems will become more important than its ability to do analysis of hardware systems. Perhaps it already is. The percentage of software functionality in a typical EV today greatly exceeds the percentage of such a vehicle’s hardware functionality. This has been true in the aircraft industry for decades. Software is and will be at the heart of car companies’ value proposition going forward, and Munro & Associates needs to increase its capability to meet this new reality. These seem to be exciting times for you and your team. I’m looking forward to hearing more about all this in the future.
End of story.
Congratulations; Sandy and the A-Team at Munro. This is the sleeping giant in the Automotive closet. My time at Magna, Ford and GM saw many...opportunities for improvement. Usually shot down by Finance or old-school management. It's high time for new 21st Century standards and the Tesla approach of true overall modular product systems thinking 🤔. Plus; get Rid of all those non upgradeable micro processor modules.
They will go bankrupt if acquire such capabilities.
One of the big problems most auto makers have with software is that they outsource it, and they can't easily make changes to if.
not only do they outsource it , they have Different systems with unique Software.
this is why VW iD cars cant communicate.
Well, from a consumer view one problem might well be that they CAN (& DO) easily make changes to it.
Basically, the consumer is being pushed out of the loop. He can't decide whether a particular upgrade is function in his particular case. This is accepted reality with Tesla. So far as I know, the "software" upgrades on other vehicles requires a visit to a dealer.
Another area where the consumers are out of the loop is in modern farm machinery. Farmers only have a "take it or leave it" approach to how their close to one million dollar machines operate.
What is comes down to is "Right to Repair."
@@GilmerJohn Kia/ Hyundai/ Genesis have last 2 years started offering firmware/ software updates for clients cars. This can be done from home & followed through simple instructions. Until now, they deliver updates twice yearly.
@@amirshahab3400 -- Interesting. I wasn't "fishing" for this information but we do drive a 2012 KIA. Is there a link?
@@GilmerJohn - Consumer is UNQUALIFIED to make those Decsions.
*I saw 40 minutes!, But as a software engineer since the 70, and if you cut me, I bleed zeros and ones, I couldn't avoid this video no matter what. And, that 40 minutes went fast! Thanks for doing this video Sandy.* *Super excellent conversation.*
I’ve been a software engineer for 45 years, greatly appreciate this content.
Gee, I write embedded code. Yes, I use the C command set, but I compile under C++. There is nothing wrong with this combo. The sensor data is appropriate to C data structures and the various comms protocols between devices. If you want to call a C++ library, have at it. No, we don't need a whole new paradigm. Only where human interfaces are concerned do we need all the kewl stuff. Most of the car compute is consumed in sensor, radar, and image processing for uses other than human consumption.
@@roberth5435 Whilst the current technology paradigm works with a narrow view, I think you missed the whole conversation. I recommend trying some Hopi Candles and have another go at hearing what was said.
C and C++ developers generally are almost as rare as honest politicians. So while you are in the vulnerable position of being perfectly equipped for the old paradigm, there is probably more than enough work to keep you going and you can comfortably ignore the new paradigm. _"Progress happens not because people change their minds, but because they die"_
One of the huge differences between the days Sandy talked about when C was they latest and greatest and today is that compute is a fraction of a fraction of a cost. Do you know how much compute is in your wallet? There is more compute on the chip on your credit card than the Apollo moon rockets. So, choosing a language based on frugal resource usage and speed is in many cases not the main selector.
@@Sidowse cost of vehicle like 40k you mentioned isn't static. as a breakthrough tech the EV needed to flex its superiority at cost. so hypercar power with in many cases better range than comparable hypercars at a fraction $$.
light vehicle with good range will be really cheap.
but this barely matters compared to cost per mile reduction.
switching takes time and certainly sticker shock but Solar EV combo will be game changer even before autonomy.
companies that do this will have a honeymoon period of better margins before competition makes them honest again and real cost reduction gets passed on.
.02 😉
@@Sidowse You, me an Elon agree that cars are too complicated and heavy.
I doubt that regulators nor manufacturers would want consumers updating software, even if they can demonstrate competence. They do likely use opensource software in the mix, but behind a locked door. There are people who can hack the cars, but as far as updating software, on a car that is used i public would be insanity if you were doing it flying blind and unable to run a tougher set of tests over it.
For smaller vehicles, i expect you can build your own and have the option at least to use your own software, but again without a team with a good understanding of the system, I would leave critical things alone.
When a firm goes bust there is usually a fairly complete parts inventory that someone picks up or gets left with. For example the DeLorean has a company who has all the original parts, still boxed and who make parts that are no longer available. Dustin's last SmarterEverDay view was about a guy who repairs tractors that are up to 80years old, making parts as needed.
I with you on the small city three-wheeler with two seats, but with Arcimoto filing for bankruptcy, which is sad but not a shock, I'll have to sick to two wheeled electric bike + two wheeled trailer.
E-bikes will be licenced for public use, regulation is currently in catch up mode, ebikes are essentially motor bikes and deserve safety considerations and restrictions in public, like anything else in a common law jurisdiction, that could cause loss or harm. My bike is currently not road legal, but for me the power is usually for towing, not toeing it.
Hats off to the videographer of this one, shooting under the chin, without a monopod/tripod, and continuously changing the lighting was something I'd never have thought to do!
I am working for a large automotive supplier, and I am highly impressed! Could not agree more. This talk is remarkably relevant.
I have soooo enjoyed this coversation. People think they got Teslas figured out but ohhh brother, the closer they think they come, the clearer they see how Tesla is ahead...
Yup. Other automakers unveil their new ev and basically it’s all about what’s on the surface. Thats followed by so called RUclips and other reviewers gushing over them one by one as they come out 🤣
@@Johnny2Feathers Just like the automotive stock analysts keep saying "Tesla models are outdated. Tesla needs a refresh to capture demand." Tesla responded by dropping prices by 20%, demand 12X overnight. Nobody is buying the Analysts picks that are edgy and new. Everyone is buying the "outdated" Teslas... lmao
If it ain't broke, don't fix it.
@@airgin3000yeah Tesla said this on Tesla autopilot day in 2019. Can’t believe people are just figuring this out.
Excellent discussion. As a almost 60 year career in software, I can assure these issues are not restricted to automobiles. More broadly speaking, it is an issue of data silos which in turn tie back to organizational structure. At one point as a newly minted DBA I worked for a retailer (no longer in business) where I tried to get their credit card operation, catalog department, and parts service departments to share their customer data. No luck! Each group thought only their data and needs trumped the thought of looking at a total customer picture.
With a slight shift, I believe BMW management recently said they didn't think their cars should be Apple IPhones on wheels. At first glance, this seems to contradict your referencing BMW as being forward looking from a software view. Probably remnants of continued siloed thinking.
Hmmm ... a real graybeard. 🧐
Spam blocked.
Conways Law in action
Sorry but its destiny for cars to be iPhone/Androids on wheels. I don’t want to use the janky infotainment software developed by the car manufacturer.
This is painful to watch. Android runs on Linux. The speaker seems to not be aware of this. He claims that BMW is moving away from Linux when they are adopting it. Also they have no idea about modern programming.
Hi Sandy and whole Munro Team. You have mention in one of your videos Electric Viking channel. He needs our support, he has hard times unfortunately!
This is the best episode I have seen discussing a topic the industry needs to solve! Sandy and Thomas - well done!
Wow Thomas really knows what he is talking about. I love that this is not some studied or scripted interview.
THANKS SANDY,AND THOMAS and the MUNRO TEAM 🤗💚💚💚
This has been a wonderful look into something you don't usually talk about. I appreciate Sandy Monroe more and more every time I watch one of his videos.Thank you very much.
Excellent topic and discussion. Very interesting. Bring more of these. The CES coverage brought more than I expected.
Sandy, this is one of your best videos yet.
It is interesting that Tesla is not using off-the-shelf software like SAP, but writes their own business management software. It makes sense to code your own solutions if you are also vertically integrated and have the capability to push the leading edge of development. Here, Tesla shows itself as much a software company as a hardware one.
Additionally, Android does utilise the Linux kernel. For entertainment, Tesla has done something similar by adopting Steam in its latest S/X vehicles.
Tesla doesn't have business people. Engineers manage themselves. It is impossible for ford, gm, vw, etc to compete in any way because the companies are controlled by business people, not engineers. If any of them wants to survive, they need to write software similar to tesla which also includes tons of automated integration testing and fire all the business people. A company ran by business people is never going to fire themselves and the rest of the managers.
Legacy auto cannot survive and will be replaced by new companies that have way less business people eating up their payrolls. Most of what legacy auto spends on payroll goes to dead weight, not engineers.
There are advantages and disadvantages of both solutions, there's no one right answer. For Tesla vertical integration is the obvious choice for many reasons. The main ones are that they have the resources to do it, and that the whole company operates very unconventionally.
@@andrasbiro3007
In this situation there is no advantage to the old system.
.
This is being demonstrated on a daily basis.
Well Tesla is a software company that happens to sell cars.
I think developing Autopilot and selling in the future is more important to them than creating good quality cars.
@@Bierkameel Well, even their execution of hardware is software inspired, so yes they are primarily a software company from that point of view. Also I'm very excited about the bot, as I think that the diverse requirements this will place on their AI development will give them an additional AI perspective which I believe will help them solve the real world driving AI even better.
Moving away from Linux to Android... umm, Android is basically Linux plus a touch-centric mobility-focused GUI (with lots of support APIs of course). So, it's not that tough of a transition for infotainment, all things considered.
Android is linux without having access to root. So you need all these silly APIs that limit what apps can do because the owner of the phone cannot manage permissions of apps. Google holds onto ownership of any phone that has android on it because only google has root access. This allows google to limit sideloaded apps so they cannot be much different than the apps in google's store. If you could easily sideload better apps, the google store would die off.
@@_PatrickO You can setup any Linux environment this way... By default actually a newly created user will not have root access. You will only be able to get that through for example giving that user the right to use sudo...
HW compatibility with Linux is much longer than android. My 6 year old CR-V has android "box/panel" which can't be upgraded with newer android thus seized. There are tv-sets which can't play Netflix due to old android versions. Not to forget couple year old mobiles which don't get security updates. Those don't support car for lifetime idea. Perhaps car for 5-7 years is supported.
@@p20071 but an addition to the tv is possible
google chromecast... fire stick etc
maybe this is a part solution
@@p20071 I don't see how it's an improvement to go from Linux (some customized distro) to Google's clutches.
Great interview, thank you Thomas and also the Munro team for providing us with such quality content.
@7:15 not only is every "hop" a latency issue, each step/hop usually includes at least one connector (usually 2 - one in and one out) - in addition to the device itself. ALL of these are additional points of potential failure. As much as Sandy hates (un)fasteners, I hate electrical connectors even more, and I'll be he does as well!
And Legas install cheap connections, antiquated, so failure risk increases.
Very impressive conversation with Mr. Mueler.
Love the no BS responses from him.
Thomas and Sandy nailed this dead-on. Today's topic is a match made in CES 2023 and I rate this A+++++.
A few things to note:
1. There is some standardization in the auto industry such as AUTOSAR, UDS, OBD, etc, but a lot of the software is replicated across the ECUs. We have used common software from ETAS, Vector, Electrobit, etc to integrate software for various supplies and OEMs, but it is costly.
2. Just because C is old, doesn't mean its bad. Automotive systems require guaranteed operation, which means having extremely detailed control of your software. C allows that, along with having been tested over the many decades. Not to say other programming languages do not, but C has a lot of infrastructure around it in the automotive world, such as MISRA and ISO-26262 compliance.
Well, having over 20 years of experience with C and some other programming languages, I must point out, that when you want to start moving from heap of small ECUs to few large powerful boxes, C would become huge burden. And don't forget, as cyber security starts being more and more important in automotive (way too late in my opinion), securing C apps is just huge nightmare. I do like C and I'm still using it a lot for programming IoT devices, where you usually have some tiny power efficient MCU, but for most other purposes, there are much more effective options.
@@MiroslavMaiksnar I agree, there are disadvantages as you mentioned. One of the many advantages of C is its use in real-time systems. Because of this, I don't see a scenario where you can have something like your braking controller being written in anything other than C. If you look non-safety critical systems such as infotainment, I think you're right, C is not necessary.
@@embeddedone C is not only language suitable for real-time applications (it is just most traditional one). But in discussed microservices architecture you can easily combine different programming languages, so you can still use C for critical tasks. And as most ECUs currently use old 90nm or 45nm technologies, high level programming language on faster modern MCU will give you better latencies than C on old HW - modern compiled languages have very similar performance to C, you just need to have control over features like garbage collector (if present), so it don't kick in during critical sequences. Or use language like Rust which does not have dynamic garbage collector at all. Personally, I'd use C or C++, as I have long experience with them and wouldn't like to experiment on critical use cases, but it's not the only option these days.
Sandy did a great job of moving the subject to relevant issues for cars. I didn't understand it all, but I will research to learn. Thanks!
This is one of the best, or is the best, video I've seen on RUclips in a long long long time.
this was one of the most interessting epsiodes i watched. And a very nice flex of hard- and software knowledge from Sandy. Greetings from germany
Moin Meisteeer
Hats off to Sandy and guest Thomas Mueller on this great discussion on automotive software
Amazing interview and fabulous information!!!! Great job 👏👏👏👏👏
Thanks so much!
@12:15 My old computing _sensei_ also taught me to always optimize for _time._ *_You can't buy a second_** Once it's gone, it's gone.*
Thank you AGAIN for a very RELEVANT discussion on a topic that is at the foundation of every product we have in our lives today and in the future.
What a brilliant interview. This is one of the best ever. Thomas gave us so much to think about.
Thanks Sandy and Thomas Mueller. 😎👍⚡
Moving away from C will cause a big performance hit unless it is replaced with a similarly capable compiled language. Rust is probably the best option.
I know nothing about rust. . . but I’ve produced a lot of C code that is still running (and earning $$$) 15 years after I hung up my keyboard.
@@dewiz9596 Many of our cars have expired due to rust. But it does sound appropriate for vehicle use. "The new 2026 Chevy - now comes with Rust!"
All chip vendors have atleast offer c/c++ complier. Rust has a long way to go. It has thus far only one implementation.
@@vrajeshkumar also, I don't think the memory management system is robust enough for embedded systems limited memory. So most development will be using unsafe rust
@@vrajeshkumar rust may make it to the main stream or it could become one of the hundreds of C killer languages that disappear, C is one of the few things that has survived more killers than Tesla
That was super interesting! I was glued to my screen…
Great contents. Move forward with automotive coding. Unfortunately, we're stuck with millions of cars using the old standards and sometimes the dealers and techs and support personnel (manufacturer) with all the expensive diagnostic tools can't figure out what's wrong with the car. They make it so complex that instead of getting out of the hole, they keep on digging.
Well, our "New" car is a 2012 model. But when something doesn't work, even the local repair shop quickly finds out what's wrong and fixes it.
Such an informative video for me. I learned so much. Thanks to both Thomas and Sandy for their insights.
Eye opening.... Thankfully I subscribed to Munro Live. So I will benefit from learning.
This is way above my paygrade. So this is hard? Complex, critical to advanced tech, and moving fast? That much I get. The rest.... glad there are guys like Sandy,Thomas, and Elon to bring it all together. Keep up the good work.
This is a fantastic discussion. I was riveted.
Killer Interview with this upload. Maybe the Blackberry QNX Muon Kernel will help with latency and also assist with movement to 5 ECUs.
I'm sure Dan O'Dowd and Green Hills Software embedded automotive realtime OS will want to jump all over this, too, and deride Tesla FSD again while at it :) except.. they are exactly the same old "monolithic lockbox" type of system that they are complaining about, vs modern Android and other software platforms... maybe Dan will target Android Auto as "inherently unsafe and dangerous!" next ;)
I just started video, always great to hear from WiPro a partner with Blackberry QNX.
Which is why Mr. Mueller was so keen to tout that BMW is moving away from linux. Sadly Mr. Mueller has his facts very wrong in claiming that a move to android is a move away from linux.
Munro Live is always good. This video is brilliant!
Thank you so much!
I have been a computer programmer for almost 30 years. I started off in C and have professionally worked in dozens of languages. Each language has it's strengths and weaknesses. C has been chosen for it it's small and fast code. It requires the developer to handle more of the error/memory checking. Which if not done right is very unsafe. Newer languages like C# manage errors/memory automatically. But it also has so much bloat. Newer developers don't understand how much bloat is behind each piece. C requires you to think. C# is going to require more space and faster processors than C. So it's a double edge sort. IMHO modular components with standard communication APIs and Secure C apis/libraries would do wonders.
PS Ford, I have a lightning and would entertain joining ;)
I like programming microprocessors in C. The discipline and form required is strangely satisfying to me. Feels like art - or religion ? 😇
@@Bora_H I love C, everyone once in a while I still write some c for fun. Learning C is a great basis to make you better in other languages. It gives you an idea on how things work behind the scenes of c# etc. I had one job writing software to merge a lottery ticket printing conveyor/ink jets all the way to the front end business. I used a raspberry pi to measure the distance travelled on a conveyor belt (through shaft drive sensors and calculations). I tested it beyond what it would ever be used. It would process 90k signals a second with the cpu at around 90-95%.
Exactly right, but more to the point, C is just another tool. You have to pick the right tool for the job. If your talking directly to hardware, C is probably a good choice, if you're building user interfaces, then probably not. You could do it, but there are other tools that are much better suited for the job.
@@RomanRomaniuk I agree, the question becomes how it is designed via hardware. If it is one system, the C with custom libraries to build the UI. If it is multiple with communications between the systems, then it makes sense to use the power of various languages.
Such a fantastic discussion. Loved this video.
Yay, thank you!
just imagining the size of those encyclopedias, is a little discombobulating....cool stuff!
never seen Sandy so deep in learning mode! excellent! thanks for a great video
Sandy, congratulations! Excellent interview.
Glad you enjoyed it!
Nice job Munro Live team. Not a sexy topic, but one that needs attention.
This is the part of the automotive industry which many legacy builders have struggled with. I remember a couple of years ago Ford invested into a campus in the Silicone Valley and some did not understand what the point was. Not sure if the investment has paid off, but it showed someone at Ford knew software is important. The recent mess VW had with their software development program shows their leadership does not understand what to do.
I know many old school piston heads hate the digital age and how it is now taking over the automotive world, but I do believe it will make the transportation experience better over all. The only thing that bugs me at the moment is the way so many are focused on subscription fees. I get, a business wants to know where their revenue will come from, but when they put heated steering wheel under subscription or remote car start under subscription, features that for decades you bought with your vehicle and got to use until the vehicle was scrapped, but now you have subscribe to those features, that sucks. I do not want to pay tens of thousands for a vehicle and then thousands each year just to keep some features we commonly have gotten over the past twenty years.
Back to the point, glad to see software in the automotive industry getting some coverage. Software is crucial to vehicles now and will be more so in the future. I hope to see more software conversations on Munro Live.
It is actually a very sexy topic, especially among people who don't think car = nice interiors.
Ford has Blackberry QNX for a partner, VW moved to Cariad a Blackberry QNX partner. I am seeing a trend.
14:45 plus 2 mins: mentally applauding, I'm hooked.
End edit: OK, can we have a Part Two please?
Love it. Reminds me of the frustration I experienced when first confronted with the legacy PLC madness in highend industrial process automation. What a farce.
Wonderful video about something we don’t often hear about from Munro.
Thomas is a smart guy and surely his skills are needed in every, not only auto manufacturer, but a much wider field of business. Very interesting video.
I think the C and Linux criticism is baseless. C has evolved over the 40 years. Android is built on Linux. The real problem must be bad code. Everything else said was awesome!
Great interview. This was, although very geeky, the most informative video (from MunroLive) in ages. Thomas brilliantly laid out obvious solutions that could save companies and babies.
I love this. Process control in chemical and hydrocarbon processing have implemented distributed control systems where all process variables come into and out of central process computers such as Honeywell TDC, Fisher Provox, Yokogawa, Rosemont, etc. unbelievable that android software may run a car. Shire didn’t know that. Very,very interesting!
Fascinating, I loved the show & learned so much, thanks.
Glad you enjoyed it!
Sandy has definitely Still got it !! I Salute you Sir !!
this is great info guys. keep up the great work.
Thanks for watching!
Wow!!!! What a content!!!, thanks:)
Glad you liked it!
It seems that with CANBus and messaging, each part of the car can take care of itself and let the other interested parts of the car ask or request info or action.
1 ECU for each door for instance. 3 wires - power, data, ground. Make the car a local network. Each individual ECU OTA updateable, like an Arduino.
-Seats
-HVAC
-Entertainment
-Drive unit
Imagine the vehicle ECU as a web server. The displays are web pages. The user has endless customization possibilities. Like a 'glass cockpit' in an airplane. Beautiful skin packages available for download.
Sandy this was a great discussion. I kept thinking oh Tesla does this or Tesla does that. You can appreciate how far the Tesla Team are ahead in thinking. 🇨🇦
Such a relief to hear someone talk about software-defined who actually knows what it means.
My interests are reliable auto braking, improve stability control, & AFFORDABLE full autonomous, most of the rest is toys.
What a brilliant discussion, there are so many points brought up by this video but if I can say something F1 has had a standard ECU for many years as well as other standard fit items, but engineers still Taylor to there own needs. The future is you will be to buy a app for a speciality off a specific team.
Awesome interesting and easy to understand, 👍👏👏👏👏👏👏
One of the TOP interviews! Thank you! Very informative!
Sandy...it's easy to understand why C and the like. It's scalable. It can run on anything from a single CPU chip to a mainframe. With such a wide range it's a perfect match for that which Tesla might be doing. That's in a general sense, of course. I'm an old Unix coder (we used to call ourselves Systems Analysts) so consider the source.
The idea of having a "skin" or a user interface that you can download into the car is a great idea. We have been driving Fords with SYNC and my wife decided she wanted a Honda. The car is fantastic but she hates the user interface/controls/displays compared to our other cars.
Absolutely gold! Wow
Interesting dichotomy between the attitude to Tesla pulling in house, seat making, hvac making, 'parts' making, which is lauded, with the view of building a standard software stacks, across marque's. ;-)
This is next level discussion and the topic is one of kind , the guest is very knowledgeable too. 👍
The whole lines of code metric is going to become outmoded with machine learning, it doesn't exactly write like that. And more isn't always the wave of the future, an engineer who can replace 100 lines of code with a few did a great job.
I don't think you know anything about code
@@mrsith1402 You'd be thinking wrong. I graduated from computer science in 2009, worked in data science for over a decade, and am dipping in ML now.
Why? Almost all the accidential complexity will still come from the actual code...
@@tipoomaster clever programing is not necessarily good code. It is an interesting discussion
Lines of code is just a simple method to assess development/test effort.
Machine learning code in itself will need its own metric for such estimates.
Just thinking Sandy programming makes me smile.
So informative. Thank you.
Glad it was helpful!
What an education!
What would you bet that Mary Barra could not learn from this video?
By law, manufacturers have to provide repair parts for 10 years. They should be required to provide software updates for security and compatibility for at least 10 years too. Those updates (and any required programming software) should be freely available for any qualified person to install.
All of those fancy screens look great until they don't work because the services are gone or incompatible when the car is only 5 years old.
I don't know jack about software (I'm mechanical), but that was fascinating.
Excellent discussion!
A reason for breaking up functionality into multiple ECUs is that it is easier to characterize failure modes. Having a lot of applications running on powerful central processor makes characterizing what happens when one or more of the constituent applications fails difficult. Can a crashed satellite radio app make antilock braking quit working? What happens if a telematics app is hacked? How are software failures compartmentalized?; can it be done without disrupting time deterministic apps running on the central processor? The other thing to consider is the wiring. Running analog inputs to a central processor requires more noise shielded wire. Thee could be merit in employing limited function networked ECUs to handle conversion to and from analog at the points of acquisition or application.
It is theoretically possible to accomplish the same compartmentalization virtually in a single computer.
Your point about signals is on the mark, but not sure whether it's really an issue. You don't need a full ECU to convert analog to digital and put the data on a bus. I don't think the presenters in the video are proposing that every sensor in the car wind up with its own wire going back to the main processor unit; that would be crazy and dramatically increase cost and potential failure modes.
Now, will auto makers follow good security and reliability methodologies to make sure software components are properly compartmentalized as you rightly say needs to happen? That remains to be seen. I don't have a lot of confidence in their ability to do so, at least not without some government regulation providing strict guidelines for the kind of consolidation of software being envisioned in this video.
This, and CPU's are cheap as dirt. So why optimize by put infotainment and critical subsystems on the same hardware. I do not want the critical stuf and the non critical run of the same power supply or use the same data network.
Although I don't think they have that in mind, but more something like consolidating software of the same criticality. And a graphical display written in c is far from perfect, so getting a more modern approach might be an improvement. Displays of all types of brands hang and crash these days, so change is good.
@@mennovanlavieren3885 Thanks, good comment.
Fascinating talk!
Thanks 👍
Great interview!! A lot of valuable information and insights!! Thank you!! 😁🙋🏻♂️
Absolutely best ever Munro live!
yes 100 million lines of code with no mistakes reminds me of playing blackjack in basic with 1100 lines of code.very good ideas are presented here and interesting instruction
Well, back when IBM was the "Be All, & End All" in computers, it was calculated that each and every "line" of code that's been debugged, etc., requires one man hour of effort. That means the code requires to 50k Man Years of coding effort. That's on the order of $5 billion$. Go ahead and make your own ASSumptions but "something ain't right" here.
IBM quietly buried their operating system mistakes by paying for their mistakes, back in the 1960’s mainframe day. They also fixed their mistakes usually within hours. Eventually, their operating systems worked correctly.
I worked with software for almost 20 years and for most people it is just an invisible thing that does something. The possibilities are almost unlimited but you have to know what you are doing. In a lot of industries they use software that is still from the 80's because its so old that most bugs are solved. And so they don't want to risk anything. You have to work with stuff that is older then you lol This video is so interesting, love hearing this stuff!
Sandy, This was a fabulous discussion of software used by the automotive industry. I have shared this video with software engineers in my church mens morning prayer group and an Intelligence engineer who is responsible for Risk Management training and evaluation.
Thanks!
Bravo Sandy!
Compliments for the excellent video! An important root of most problems mentioned in this video is 'enginering by catalogus' (as Elon calls it), so stitching 30 to 100 components (eg. HVAC, infotainment, motor-management) from different suppliers together by Canbus networks. I prefer to call that 'cut-and-paste cars'.
We should learn all the dumbo's that there are two types of cars:
1. 'integrated cars' (Tesla and the Chinese brands) and
2. 'cut-and-paste cars' (the rest).
So tell your Grandma!
Great discussion - I think this goes a long way in validating that the likes of GM, Ford etc are screwed - there is no way they can even get close to this, maintain it, evolve it and be competitive longer term…
Kiitos!
Thanks
This was painful to listen too! The complaints Sandy had about embedded based systems makes me think he has been out of the automotive development cycle too long! The C-programming language was developed in the 1970's for a UNIX based system, it really did not gain popularity in the automotive industry until the 1990's mainly because of the cost and complexity of the tools, and toolchain. Additionally, Google Android is based on a Linux root (open-source). Note, Android has limitations, and is not used for safety critical functions. I'm surprised they did not touch on "open-source" vs proprietary SW.
It got more painful towards the end when Mueller was really pushing his business venture by talking about 3rd party downloadable skins on safety critical systems. Is this a joke?
I'm sure the OEMs will fight tooth and nail against open sourcing any car software "for the safety and convenience of our esteemed customers".
@@jamesvandamme7786 but what is the point? 95% of the software can't be downloaded and used by anyone except other car companies. It's not like people will be updating their own car sw or inviting 3rd parties to replace sw.
Outside of the tuning space and occasional Android headunit hacks. But that's in the 5% realm
Hoping for more discussion with this guy.
This needs to be watched by every automotive OEM. 👍👍🇺🇸
Having spent 30 years in the IT industry when someone tells me that a car has, on average, ten times more code than a massive commercial airliner my instinctive response is to question why the car maker would not scrap their system and start from scratch with a spec of what the system is supposed to do. And all those ECUs? Argh! Each has to have at least one comms connection, one sensor connection and one power connection; add the ECU itself and each ECU represents a minimum of four possible points of failure…. Madness.
Great episode, a banger!!
Wow Thomas really knows his stuff and is extremely good at explaining complicated things.
Thousands of Tesla fans would love to learn much more about how the software in a Tesla works!
And a lot of them would love to hack into it. Seems to me that if a Right to Repair law applies to every other electronic gismo, that it ought to extend to electronic autos.
Great interview guys. This is what WS is missing and what Legacy is struggling with with a behind the scenes as to why and how much IT MATTERS. Tesla is more than just a '"car company" and the definition of a car company now will be based on it's software as we valued engine specs and transmissions.
More lines of code is not better.
As Elon once said, I give my team 1 point for adding a line of code and 2 points for deleting a line of code.
Exactly.
Yes, at first you write something that does the job. And then you start the optimization. You want that thing to run with the least written code possible.
IBM once famously berated Microsoft employees for their low count of KLOCs (thousand lines of code). I guess they would have been overjoyed to find 100 million lines of code in an automobile. To me it sounds absolutely nuts.
It was great! Sandy you are a young guy with 74 years of experience!
Great video 👍
Thank you!
Such an important topic. Traditional Automakers are mired in outdated technology & software that takes years to update. They have got to adopt modern centralised computing on upto date hardware & software, otherwise they are going, the way of the dodo...