supervisory board of VW has 20 members, state of Lower Saxony appoints 2 (as a minority shareholder), workforce elects 7 among themselves, and 3 are trade union representatives also elected by the workforce.
no one is denying it's a for profit company, but its governance model doesn't really scream "neoliberalism". assuming you're from the US, (German) enterprises like VW are vastly different from what exists in the US, not just in the terms of their structure but also their influence on Germany and EU.
My favorite impact that I've had on my organization was the "no agenda, no meeting". It became a meme, minutes before the agenda-less meeting was supposed to take place someone would send it to a meeting chat or email, usually followed with ":)", especially if I were one of the attendees. In the rare cases I forgot to follow my own stubborn rule then it was a whole show, in hindsight, probably should've broken it at least once a quarter along with some penance to really help cement it.
However, I managed to "bully" everyone into following this simple rule because I had some influence in the organization; I was a manager of a large department.
Unfortunately, interns will probably get an eye-roll for such suggestions, even if they reference their superior's rule.
My point is, don't send you colleagues this link, you will come off as rude. You'll get further by e.g. feigning surprise to the lack of agenda, and maybe you get to use that opportunity to spark a conversation about the importance of an agenda. If you're a manager and above, then by all means, use your influence to force it, it will make everyone's job easier in the long run.
Oh, as for the messages that contain only "hello", just ignore them, they will either solve their own problem or quickly jump to the point once they tire of waiting for your equally pointless response. Or just have a chat with your colleagues every once in a while, maybe they genuinely care about you and your cat.
(I'm going to assume you're serious). Only in the tech bubble could a hobby which is challenging and probably gruesome at certain points, be held against you. In any normal conversation a person who climbs literal mountains would be looked at in a positive light. Not saying it's the one defining quality you'd need to successfully run a company, but you somehow managed to place it at the completely wrong side of the proverbial scale. Of course, it's probably completely insignificant and uncorrelated, but I wouldn't be surprised to read that someone who plays a piano is also incompetent to run a company because ...I don't know, I guess I'll have to wait to read that one here soon.
Me, I think "moonshot" is a very buzzy buzzword, not a concrete thing, despite what it's named after. I've listened to both Chris Hadfield's "An Astronauts Guide to Life on Earth" and Richard Wiseman's "Shoot for the Moon", and it was extremely clear how little there was in common between the perspective of the professional psychologist and the guy who actually went into space.
Something can be good for X overall but be bad for subsets of X. The fact that you find it so offensive for me to even make that statement says more about the mono culture you view the world through than the one I view the world through.
edit: Of course Google, the king of the tech bubble, saw this as a positive so your statement about this being a tech bubble thing is also really amusing. If anything the tech bubble would likely agree with you so you're part of the tech bubble mindset on this one.
The point he’s making is one person cares about doing the task as efficiently as possible in a new way and the other cares about performative behavior done in a performative way.
He has a point. The point is inventors don’t care about repeating performative tasks like climbing a mountain everyone has already climbed before in the same way everyone else has.
> “In any normal conversation a person who climbs literal mountains would be looked at in a positive light.”
It’s irrelevant to most conversations. Someone who regularly brings up their mountain climbing unprompted doesn’t necessarily appear in a positive light.
4680 is a cylindrical cell format, the number you quoted refers to the cell itself, when packaged into a battery with busbars, cooling, etc., the gravimetric density on pack level for model 3 is around 125Wh/kg. the number listed by BYD is 150Wh/kg pack level density. the cells themselves are probably around 200-250, but they require less packaging effort due to the fact that the cell housing for prismatic cells already incorporates various mechanical and safety features.
i haven’t checked any of the numbers nor have i seen 3rd party analyses, but it definitely follows the trend: prismatics keep getting better and they might ultimately win the race once we get to solid state and thermal management “solves itself”
One would expect that a site dedicated to clean energy would know the difference between watts and watthours (i.e. power and capacity), on several occasions it claims that the capacity is X gigawatts instead of gigawatthours (GWh). It's hard to figure out what exactly is getting installed as the relation between the two is often different depending on the spec of the system.
The capacity of the connection they can saturate is in GW. The capacity they can store is in GWh.
Power generation is generally in GW, and if you're trying to work out how much demand you can satisfy, then that's what you want to know. If you're trying to work out how long you can satisfy it for then you want GWh.
It's even more confusing when those two numbers are the same which does sometimes happen. However, for grid storage it's more common for the GWh number to be 2-4x as large as the GW number.
If you follow the link on their site, the eia.gov site also reports the batteries in GW. They are consistent about this across their sites, so it isn’t an accidental error… but I can’t for the life of me recall why they do it this way.
That may be true for its fit and finish (panel alignments etc.), but the fact that they mastered vertical integration and supply chain management in less than 10 years is beyond amazing. Their powertrain (battery, motors, other hv components like charger etc) are first class and unparalleled in performance (and cost). We’ll see what Lucid will achieve in the next couple of years, their claimed (and validated) numbers such as range are very impressive, but for now, but Tesla has proven that it is a hardcore engineering company in a few important areas, there are others that need to catch up.
I don't know where you get your information, but you've completely missed what automotive software development looks like. The amount of verification and validation, and the number of standards (most of them are self-imposed, not a legal or homologation requirement) is absurdly high.
Here's a scenario. You're nominated to be an ECU supplier or a software sub-supplier for a VW brand, first thing they hit you with is requirements which span 1000 pages for a simple system (door, seat, HVAC), or 10x more for a more complex one (infotainment, engine ECU, "main" vehicle ECU etc.). 1 of those requirements is "SW shall comply with VW 8xxxxx norm" which is one of many VW norms that they deliver to you. The other requirement is "SW shall comply with KGAS", KGAS stands for "Konzerngrundanforderungen Software" which translates to "Group Basic Software Requirements", (group is VW), and both, you guessed it, are thousands upon thousands of requirements.
Then there's Functional Safety, or FUSA, which is a reference to ISO26262 (based on IEC 61508). Then there's also ASPICE (ISO/IEC 15504). New thing is UNECE R155 (cybersecurity). These three prescribe a very detailed development process commonly known as the "V model" for system and software development, which means you need to elicit requirements, define system requirements, system architecture, software requirements, software architecture and software detailed design. After that, you get to coding. For each of those there's a validation method: unit tests, software integration, software qualification, system integration and system qualification. ASPICE 4.0 has expanded to cover Embedded Hardware and Mechanical design as well. Other than the engineering processes they also cover other areas such as project management, configuration management, supplier monitoring, problem & change management etc.
Then come the external and internal audits, pardon, assessments. Your internal Quality department needs to monitor all engineering activities and report them to the customer, customer's Quality dept. will do their own audits, you and them will also hire an independent company to audit/assess you so that there's no bias.
BUT guess what - almost none of this is required for non mission critical software, so your infotainment is actually the only thing developed in a way you've described it. Brakes, ABS, ESP, Engine ECU or the EV powertrain (BMS, inverter etc.) are all written according to what I described above. There's no need for more bureaucracy, the automotive industry (especially German one) is very good at self-regulating and would make an average web developer throw up on his first day. Failures of the UX/UI in modern vehicles is just a business problem - guys who spent decades building and selling options like leather seats, and checking spreadsheets at the end of a fiscal period are still at the helm or their business processes still live on in those companies.
Rimac Technology | Embedded Software Engineer | Onsite or Remote (Croatia/UK or Europe)
Rimac Technology is an electric vehicle powerhouse, the Tier 1 supplier behind the world's most advanced and most powerful, record-breaking hypercar - Rimac Nevera. A part of Rimac Group, Rimac Technology and its sister company Bugatti Rimac are on a mission to electrify the exciting world of super-sport cars and help our customers electrify their fleet through our portfolio of battery packs, e-axles, infotainment and connectivity solutions.
We are hiring embedded software engineers to work on various products and projects for world renowned OEMs and our group's next hypercar - the successor to Bugatti Chiron.
We are looking for:
- passionate engineers with good communication skills
- experience with real-time embedded systems
- automotive experience _not_ a prerequisite
You can contact me or send me a CV @ david.romic@rimac-technology.com
I'm in automotive, but we have similar requirements to medical.
There's no "100% fail proof" solution, it's about determining the modes of failure and addressing them individually and combined, minimizing the risk and defining an acceptable level of it. If you accept that failures are inevitable, which they are, some are likely, some vary rare, you can prepare for them via redundancies, fault tolerant design, etc.. It's also about doing proper system design and performing certain methodologies such as "Failure modes, effects, and diagnostic analysis" (FMEDA)[1], "Fault Tree Analysis" (FTA)[2] and accounting for those.
There are standards like IEC 61508[3], or its automotive adaption ISO 26262, with which certain engineering disciplines and fields must be audited against in order to pass certifications and be able to market the product. In case of ISO 26262 it's not mandatory (will be soon), but good luck explaining any judge or jury why are you the only company in the existence not applying it in your vehicle design.
