Wilhelm Svenselius

Last week Polestar published it's Annual report. Here are some interesting bits: - Polestar 3 uses NVIDIA DRIVE core computer, running software from Volvo Cars. The infotainment system is powered by a next-generation Snapdragon Cockpit Platform from Qualcomm Technologies, Inc. - Polestar 4 is built on the premium Sustainable Experience Architecture (SEA) developed by GEELY Holding. The rear-view mirror is replaced by a high-definition screen that shows a real-time feed from a roof-mounted rear camera. Polestar enters a royalty agreement with Geely and Zeekr for it's use of the common platform, especially outside of China. - Primary battery suppliers are LG Chem Ltd and CATL (Contemporary Amperex Technology Co., Limited) - For Polestar 5, Polestar entered into a technology license agreement with Geely related to the right to use Zeekr Europe's ZEEA2.5 and Geely's GEEA2.0 electrical architectures. They are in agreement with SK-On as a battery supplier. Polestar 5 will build on the Android OS for its infotainment system. - For vehicles in China, the FlymeAuto OS developed by Xingji Meizu is planned to be developed into a seamless operating system, including in-car apps, streaming services, and intelligent vehicle software. Polestar and Xingji Meizu's joint venture will be the sole authorized sales and service entity for Polestar vehicles in the China. To read the complete briefing for free -> https://lnkd.in/dcNjE-HZ

3

I've seen this picture circulating a lot since Monday, and personally, I stand by its sentiment regarding both iOS and Android app development. However, when asked, I've always maintained that cross-platform app development has its place in the industry. In my opinion, there are several reasons one might choose cross-platform development: - A startup looking to enter the mobile app development world might not want to invest heavily in hiring both iOS and Android developers. - A company with a strong React engineering team, seeking a companion app for their eCommerce platform, could explore React Native to test the waters. - A Microsoft-oriented company, aiming to keep costs internal with minimal additional training, might opt for Xamarin. - You could be developing an app with a short lifespan, such as a temporary marketing app or data collection apps used by sales reps with a variety of personal phones. Regardless, I'm convinced cross-platform development has its place. However, the purpose of this post is to express my confusion at larger organizations shifting their teams to React or Flutter despite having established native iOS and Android apps. I've attended many talks and read numerous books and papers on the pros and cons of both approaches. Ultimately in my opinion, if you want your app to be at the forefront of technology, you need to go (or at least stick with) native app development. I'd love to hear some success stories about this. While I'm not looking to be convinced to change my mind (I'm too set in my ways, I'm afraid), I am genuinely interested in hearing people's thoughts and experiences regarding the decision and transition to cross-platform development.

47

38 kommentarer

It‘s about time to say goodbye. To my fellow workers of both BMW and QC, since even during the time at QC I continued to work in the cooperation project for autonomous driving. But it is also time to say goodbye to the domain of autonomous driving. During the last 7 years working on this domain I met probably hundreds of people. There are some truely awesome software and data developers and architects among them. I am going to miss you folks! Mohamad Alsioufi Viacheslav Rodionov Jinho Kim Adina Schauß Daniel Danch Marc Bartholomäi Dr. Sandeep Pandey Jake Vizzoni Noam Shaish Jan-Stefan Fischer André Roskopf Andreas Falkenberg Aubrey O. Felix Althammer Deepu Dilip Junjie Tang George Pucea Felix Müller Matthias Lein Johannes Handloser Michael Pershyn Vitali _. Amila Wathudura Jonathan Bryan Schmalhofer Dr. Jochen Thäder Dominika Makuch Jennifer Raß geb Reinelt Vasco Varduhn Martin Roderus Piotr Milewski Alexander Kruck Lawrence Louis Olga Mykytiuk and many, many more... just tried to tag some of all of you folks, many already working at different roles or at different companies, but it always has been joint effort to get something done. There is probably many more that don't use LinkedIn, say hello to them from me :) But what I am not going to miss is this domain of autonomous driving. But why? Well, starting in this area some years before it was a feeling to work on technological challenges. But later down the road it became more and more a struggle with the companies and their structural and organizational problems. Maybe I am going to write down more of this as an experience report from a developers probing of view later…

58

12 kommentarer

HQ in GOTHENBURG – WHICH SYSTEM WILL BE USED IN THE DEVELOPMENT WORK? Today's big news in automotive is Volvo Group's and Daimler Trucks' decision to proceed with a binding agreement on the development of a platform for software-defined vehicles - so-called SDVs, "Software Defined Vehicles" - for heavy trucks. The agreement is based on a 50/50 deal and follows an earlier announcement from the companies, from May 2024. The SDV platform aims to set an industry standard and the plan includes a head office in Gothenburg. The companies note that the partners' joint goal is to, “develop a truck operating system and to offer the joint venture's brand and versatile application-agnostic products to other commercial vehicle OEMs.” But despite this, competition between the companies must be protected and maintained: "Volvo Group and Daimler Truck will remain competitors in all other business areas and will continue to focus on an independent product and service offering." Today's announcement will undoubtedly strengthen the digital transformation not only within Volvo and Daimler, but also within the transport industry. Not least because we are talking about the truck industry's two largest manufacturers. An SDV is a vehicle where core functions are handled by a software layer that sits between the driver's or "fleet manager's" vehicle interface and which handles vehicle functions primarily via sensors. This allows the manufacturer to improve both usability and features dynamically via updates, including wireless. This is an interesting venture, not least because software-defined vehicles are the next major line of development in the automotive industry. But also because it is the second example within the framework of a couple of years where Volvo and Daimler join forces in an important development area. Previously, since 2020, Volvo and Daimler Truck have a joint venture underway around fuel cell solutions to power the vehicles. Then the Volvo Group bought 50 percent of Daimler Truck Fuel Cell GmbH & Co for a joint development of energy solutions for heavy trucks whose electricity for the batteries is generated from fuel cells powered by hydrogen gas. With the now announced SDV investment, the companies move forward together and share the significant development costs. Undeniably a smart move. But there are challenges: for example, which systems should be used in the development work? The PLM side is one thing, while software development can land elsewhere. Anyway: Volvo Group has on the PLM side PTC with Windchill as cPDm solution. On the ALM side, PTC's Codebeamer, together with Windchill, will play important roles in PTC's offering. This while Daimler basically works in Siemens environments with Teamcenter and NX CAD. As far as the software side is concerned, Mercedes has used, among other things, IBM Doors. Siemens' ALM solution is called Polarion, which presumably has good hopes of getting into Daimler. The development will be interesting to follow.

Here's my take on Volvo Cars's update from their Capital Market Day: 1. Firstly, Kudos to Volvo for sticking to their existing platform and using that as the basis for their new generation platform SPA3. I see many OEMs, due to various reasons, struggle with staying on a platform. Every development project ends up being a new platform. 2. Close and direct collaboration with CHIP vendors like NVIDIA and Qualcomm are beginning to payoff. From an automotive OEM's perspective, we are barely a large customer for these companies. The main reason as to why I think this is important is the realization that "You can only abstract so much in SW" and when we get into the details we understand what can be limitations or enablers if we had a different HW platform. And this requires a close working relationship with chip vendors. 3. Superset techstack is in my view the way to go. Instead of projects and programs in the driving seat, the superset platform has to have a life of it's own where all resources can be used for it's development. And the various outcomes of the platform is merely an abstraction. Remember, it is always easier to take things out of the platform than to add it last minute. Read the entire issue for FREE here: https://lnkd.in/daZXedVp #volvo #nvidia #qualcomm #chip #semiconductors #automotive

2

Busy second day at Connected Vehicle Systems Alliance (COVESA) - #AMM meeting in Sweden. I liked the panel about Complexities of moving towards Software - Oriented approach where Brian Carlson, Michael Niklas-Höret and Yu Fang explained the challenges that faces us in this challenge- from hardware to homologation and costs. I particularly enjoyed the presentation from Magnus Feuer - cleverly named “How to unsuck your software” where he described the organisational changes that need to happen to eliminate high costs and bring more efficiency and clarity in software development. Now this is a subject close to my heart - because I believe that the quality, cost, complexity of the software development is directly connected to the organisational setup and the efficiency of it. This is exactly what we focus on in SMART Engineering & Development. We help companies implement an efficient, easy to understand software development framework - made by engineers for engineers. We do not just implement a workproduct - we transform organisations towards efficiency and optimisation. If you want to know more about us and how we can optimise your software development and make it fun and exciting again- drop me a comment. #software #softwaredevelopment #covesa #automotive

37

3 kommentarer

A great article worth reading with all the details even with a translator. Electric cars from China can cost three times more in the West than what they are sold for in their home country. There are several reasons behind the low prices. China has to do with the ongoing price war in the country. In addition, it is said that several of the manufacturers received government subsidies. A key for a car manufacturer like BYD has been to lower the prices of its batteries, which are the electric car's most important component. Chinese automakers have spent 20 years securing mines around the world that have access to the key battery components lithium and cobalt. BYD, which then manufactures its own batteries, can control its costs at a completely different level compared to its competitors. It also means that Chinese car manufacturers' capital investment per vehicle is significantly lower than their competitors from the West. #electricvehicles #evs #futureisnow

7

1 kommentar

How could we support OEMS in lowering their CO2 through services around AI and electrification? That is what this two year research project has been about between WirelessCar and Halmstad university, please read the final article! https://lnkd.in/dhp9vx5a

28

2 kommentarer

🚗Why are so many OEMs going for joint ventures to meet their SDV goals? 1. OEM's on their own are beginning to understand the efforts it takes to develop all the software in-house(assuming that is their definition of being SW defined). The cost of the efforts for their company is simply not justifiable. But the math works out if there are multiple OEMs that can pool their resources to develop common solutions 2. There is an underlying fault in this line of thinking. When common solutions are being developed, the solution is averaged out among all stakeholders. Meaning, the best of solutions AND the worst of solutions don't end up getting produced. 3. One reason for all these joint ventures is the regulation that is pushing OEMs to team up to enter new markets. (China). These started out as production partners but now it has gone beyond that and there is an active exchange of technology. 4. Strategists in these different companies are looking for a "solution" that they can present to higher management and the board. And a collaboration with another established OEM seems like prudent thinking at first. But as we get to the details, it might not be the case. 5. Lacking vision: OEMs that are "just" trying to be like Tesla is not a vision. So they end up creating all these scenarios to justify a high R&D and SW spend. And even when that does not begin to show in the balance sheet. They look for other more "palatable" strategies. I have a running hypothesis: The bigger the company the faster the knee-jerk reaction to buy or borrow instead of building. Read the full report for free: https://lnkd.in/dqjds2Fs

6

3 kommentarer

I just r e a l l y have to remind myself that Claude is not actually intelligent and thinking like I am. Because damn it does a pretty good job at faking it. “I ask because I can see interesting parallells between this axis and how software development has evolved…” Exciting news on GenAI at Scania Group coming this week by the way so stay tuned! #genai #aiadoption #claude #turingtest #elizaeatsdust

35

3 kommentarer

🚨Is In-car karaoke the whole point of SDVs? 1. NIO and BYD partnering with Stingray to have in car karaoke 2. The whole point of an SDV is to enable such integrations late in the product lifecycle without having to incur large costs, for example, updating to a new hardware. 3. Conversely, if there is a need for a hardware dependent or a feature that is tightly coupled with specialized hardware, then it is inevitable but to upgrade or add-on this new hardware to the vehicle. 4. SDV cannot solve for hardware dependency. SDV, if done correctly, with the right layers of abstraction can only shield the rest of the vehicles from large changes or reduce the magnitude of such a change. 5. Becoming Software-defined does not mean you can be agnostic to the underlying technology. Although suppliers, tools, vendors etc. will try to sell this idea, it is simply not true. More importantly, the real question is, if it is of any business value to achieve hardware independence. Is that where the constraints lie today? Read the full report, with sources and more context, for FREE:

2

What if you could still benefit from model based design w/o compromising on code quality and modern development workflows 😉. Then look no further and check out #ascet. https://lnkd.in/dHyBSM5z ASCET model semantics are saved in ESDL which is easy to understand text based format and not cryptic xml or non readable binary formats 📑. Its closer to code by design using familiar software notations👩‍💻 Push code to git, review, diff and merge. See here a live example on github 👍 https://lnkd.in/ewg-uDTG Built in static analysis find errors at editing time 🔍 You can still  ✔️ Prototype your ideas fast using simulation. See https://lnkd.in/eC6CX5Jf ✔️ Do test driven development using built in unit tests. See example here https://lnkd.in/egdHUvau ✔️Auto generate high performance code which is MISRA compatible. See example here https://lnkd.in/ePWJEnb8 ✔️ Integrate into your automation pipelines ✔️ Generate software documentation Give it a try  https://lnkd.in/dZKvbMRv #embedded #modelbaseddesign

20

A Plattform can help for safety and requirements engineering for automated driving? I've worked with 10 companies and identified similarities, worked it out with my team.... Requirements, Architecture, Safety always seem to be a big questionmark in any company.... But in the end they all look the similar... Why? You build products with the same intention and need to write according to the same standards... Automated Driving in Cities, on Highways, in Parking Lots....ISO 26262, A-SPICE, ... So I decided to build up own Requirements based on Regulations and Safety Analysis, Scenarios and Hazards to accelerate autonomous driving development..... Look at this example from UN-ECE 157 to Sensor Requirements. Are you ready to learn more? Just ping me

21

8 kommentarer

Last week of August has been different this time around as a week of "transition". The weather has been great, letting us enjoy the last few good weeks of summer before we head into fall. On a professional front, a dream run of 4.5 years at Volvo Cars has come to an end. I had the opportunity of accumulating massive technical know-how within Electric Driveline Development & Verification. Below are some reflections that I wanted to pen down 😊 𝗖𝘂𝗿𝗶𝗼𝘀𝗶𝘁𝘆, 𝗶𝗻 𝗿𝗶𝗴𝗵𝘁 𝗺𝗲𝗮𝘀𝘂𝗿𝗲𝘀, 𝗱𝗼𝗲𝘀 𝗻𝗼𝘁 𝗸𝗶𝗹𝗹 𝘁𝗵𝗲 𝗰𝗮𝘁 Being curious & asking questions puts things into perspective. Working within the Propulsion Test Object team, I received a "Motfråga" every time I asked one. What a fun way to learn! People were curious about the origin of my questions. 𝙏𝙝𝙞𝙨 𝙬𝙖𝙨 𝙦𝙪𝙞𝙩𝙚 𝙝𝙪𝙢𝙗𝙡𝙞𝙣𝙜. 𝗖𝗵𝗮𝗻𝗴𝗲 𝘁𝗮𝗸𝗲𝘀 𝗰𝗼𝘂𝗿𝗮𝗴𝗲  You will always learn something when you choose change. I was lucky to choose the change I wanted, when transitioning from the role of a ScM to that of a PIVE. Enrolling into the Electric Driveline course at Yrkeshögskolan while working, equipped me to ask right questions. The courage was not just mine, but also from the leadership & peers who believed I could learn & scale quickly. 𝙏𝙝𝙞𝙨 𝙬𝙖𝙨 𝙚𝙭𝙩𝙧𝙚𝙢𝙚𝙡𝙮 𝙧𝙚𝙬𝙖𝙧𝙙𝙞𝙣𝙜. 𝗟𝗮𝗯𝗲𝗹𝘀 "𝗗𝗼𝗻'𝘁 𝗔𝗽𝗽𝗹𝘆"  "Unknown" scares humanity. So we tend to conveniently label things. Yet, it can be immensely liberating to break & diversify these labels. Possibility to discover newer labels - ScM, PIVE, "Fröken", Template creator, Meeting notes taker, One who can find answers 𝙝𝙖𝙨 𝙗𝙚𝙚𝙣 𝙚𝙢𝙥𝙤𝙬𝙚𝙧𝙞𝙣𝙜. 𝗕𝗲𝗶𝗻𝗴 𝗿𝗲𝘀𝗽𝗲𝗰𝘁𝗳𝘂𝗹 & 𝗰𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝘁, 𝗯𝘂𝘁 𝗻𝗼𝘁 𝗦𝗼𝗿𝗿𝘆  "Sorry" is a word often misused & misunderstood. I remember a valuable feedback from my manager in 2021- "YOU DON'T HAVE TO BE SORRY ALL THE TIME. You are here to do a job which needs you to discuss/ disagree/ ask questions & that is okay. You don't have to be sorry for asking for their time". This feedback was gold! 𝙄𝙩 𝙘𝙝𝙖𝙣𝙜𝙚𝙙 𝙝𝙤𝙬 𝙄 𝙖𝙥𝙥𝙧𝙤𝙖𝙘𝙝𝙚𝙙 𝙢𝙮 𝙬𝙤𝙧𝙠. I became tremendously aware & more respectful of the others' time. I made sure to prepare extensively in advance & the quality of their answers increased. 𝗕𝗲𝗶𝗻𝗴 𝗸𝗶𝗻𝗱 𝗱𝗼𝗲𝘀 𝗻𝗼𝘁 𝗰𝗼𝘀𝘁 𝗮𝗻𝘆𝘁𝗵𝗶𝗻𝗴 I realized quite early that I should be respectful of the boundaries set by others. Yet a beautiful bond of friendship can be created by blurring them. Intentional small talk next to coffee machines, checking in on the sick colleague, a short nod/smile of recognition when passing by, are actions that NEVER go unnoticed. 𝙎𝙪𝙘𝙝 𝙘𝙤𝙣𝙨𝙘𝙞𝙤𝙪𝙨 𝙘𝙝𝙤𝙞𝙘𝙚𝙨 𝙝𝙖𝙫𝙚 𝙚𝙖𝙧𝙣𝙚𝙙 𝙢𝙚 𝙢𝙖𝙣𝙮 𝙬𝙚𝙡𝙡 𝙬𝙞𝙨𝙝𝙚𝙧𝙨 𝙛𝙧𝙤𝙢 𝙩𝙝𝙞𝙨 𝙨𝙩𝙞𝙣𝙩, 𝙛𝙤𝙧 𝙖 𝙡𝙞𝙛𝙚𝙩𝙞𝙢𝙚. As this chapter closes, I carry these reflections to my next assignment at Volvo Group Aftermarket Technology (GTT) hoping for newer learnings & friendships. #reflections #newjob

237

39 kommentarer

tl;dr There is a huge benefit that you can achieve by shifting left and finding bugs closer to their source. However, if you try to accomplish it without proper planning, it will only result in frustration. --------------------------------------------------------------------------- The shift left challenge that I mentioned in my last post is typical for operations in DevOps. The mainstream belief in DevOps (as well as other technology fields) is that technology is the solution. If you have challenges in a workflow, start looking at new tools or features to overcome them. However, the truth is that technology is only an enabler; if you don’t change your processes, the technology will fail. When you want to take advantage of a DevOps methodology, such as shift left, the pure technology approach is to throw all your tests into your CI pipeline and expect that it will give you the best results. To do this properly and gain the shift left benefit, you must take some time and analyze your total quality pipeline. On PR (code submission), for example, you only want to reject a code submission if you are confident that the reason for the failure is the newly submitted code. Tests must be categorized properly so that they can be executed in the correct place (multi-tier testing). The specific categorizations that should be considered are Test Type and Test Severity. On PR, you’ll generally want to execute all unit tests, your entire regression suite and critical and high severity functional tests. This set of tests should determine that the code is “good enough” to be merged. After code is merged, it should go through another round of testing (CT/Continuous Testing) to incorporate the longer running tests and additional test types. This round of testing can either be done immediately after merge, or on a regular cadence such as nightly. Any test that can reject code return and absolute pass/fail result. However, there are tests that need to have their results analyzed, such as performance tests and tests with variable thresholds. If these are executed automatically all the time, you are going to drive your triage and debug people crazy. It is possible to define a set of tests in these categories that do return absolute results, but they must be planned and implemented very carefully with an exact scenario in mind. In summary, understand your problem, analyze your environment  and design the proper solution. #iworkforgm #GMrs_lead

9

Thought of the day: "United we stand divided we fall" People working together are more likely to be successful (effective) than those who work individually. Same is true for ADAS systems like AEBS, LDW & DMS. If these systems work together, they can handle many more scenarios and can be used to improve the overall performance & effective ness of the system. For example, driver distraction cases like driver talking on phone or driver looking sideways or towards the infotainment screen even though dangerous may not always be disastrous (like on empty stretch of road with a controlled within lane driving) , the situation will only escalate if obstacle is detected on collision path or lane deviation is detected Under such circumstances the distraction threshold and duration both can be slightly relaxed (to avoid driver irritation) if no danger is perceived for next 3 seconds by other systems like #FCWS / AEBS and #LDW. Unfortunately, #DMS as a standalone system without the knowledge of on road conditions will result into unnecessary irritation to driver though distraction warnings as soon as his eyes are off the road Similarly, if the driver is drowsy and even though #DMS sounds an alarm, it will take some time for the driver to wake up and get into his full senses, unfortunately this delay could be good enough to cause an accident, this situation could be easily handled through #AEBS by applying brakes or active #DMS which cuts off accelerator pedal This is the main reason why at Starkenn Technologies we have developed a 360 Degrees safety system, where all the systems work together to reduce accidents by alerting driver and also taking proactive actions like accelerator cut off / braking and at the same time avoid unnecessary alarms which might irritate driver (which may eventually result into switching off the safety system(s) by driver)

17

Nuro has announced a strategic pivot towards licensing its self-driving technology to carmakers and mobility companies. After experiencing layoffs in 2022 and 2023, the company aims to focus on its core autonomous driving technology rather than operating a fleet of on-road delivery bots. By transitioning to this new approach, Nuro seeks to extend its financial runway from 1.5 to 3.5 years, emphasizing the development of AI technology. The company plans to offer full Level 4 autonomous driving products tailored to goods delivery and passenger mobility services, while also collaborating with OEMs to develop automated driving solutions for consumer vehicles ranging from Level 2 to Level 4 systems. This shift marks a significant evolution in Nuro's business model and industry positioning.

75

Last week, I was getting ready to present a system migration to our developer groups. This change was going to impact a lot of workflows, require some teams to make some structural changes in their code base and introduce new best practices to prevent performance issues. I was expecting the presentation and ensuing discussion to be very heated. Generally, I’m very prepared for disagreements. I follow open decision-making practices and take note of all feedback and concerns before returning with a finalized design. It is very rare that the final design is identical to the initial one that I present. In this case, however, the major pushback that I was expecting was regarding the system that we were migrating to.  However, this was an executive decision that was handed down. Neither me not my team was involved in any aspect of this decision. Our responsibility was to ensure that all the teams understood the impact of the change and were fully ready by the time the migration happened. I needed to have an open discussion on all the areas that were within our control, but completely shutdown any discussion on the aspects that were out of our control. While engineers do need to vent, I didn’t want to take up the entire meeting on this. To accomplish this, I started off the meeting by talking about the migration and very clearly and directly said, “This migration is not my decision or my team’s decision. I am not prepared to discuss the reasoning behind it, as we were not stakeholders in the decision process. We are accepting this migration as something that is going to happen and are now discussing the implementation details, the impact and how to get the best experience from the new solution.” I ended up having a good discussion and got great feedback and questions about the parts that we were responsible for. It’s super important to clearly define the boundaries for any technical discussion. Without those boundaries, the discussion can go in so many different directions that are completely irrelevant to why you are there in the first place. #iworkforgm #GMrs_lead

12

2 kommentarer