unhandled
Well-Known Member
- First Name
- Mathieu
- Joined
- Jul 28, 2021
- Threads
- 13
- Messages
- 176
- Reaction score
- 173
- Location
- Stoke, Quebec, Canada
- Vehicles
- Mustang Mach-E Premium AWD ER
Many organizations have adopted DevOps for embedded systems, something seemingly impossible based on previous posts. Here are a few references I found that suggest otherwise:
The Scene of DevOps in the Automotive Industry - DZone DevOps
Embedded DevOps: Implementing CI/CD in Embedded Development (windriver.com)
Tooling for car manufacturers to do DevOps
DevOps for Automotive Companies and OEMs With the JFrog Platform
It's also strange if Daimler is looking to hire DevOps engineers for their embedded systems. Maybe we should reach out to them to let them know it can't be done. Would save them a bunch of money!
DevOps Engineer for Autonomous Driving platform (all genders) - in Berlin| Daimler > Career > Job Search > Job Postings
Side note, I also happened to have found that Ford uses that manage OTA:
Customer Success: FORD MOTOR COMPANY | Wind River
To prove that all execution branches in a piece of software have been exercised of that a program logic is sound is difficult for sure but it's definitely a topic of active research. Languages have been developed to tackle that particular challenge, recently in the world of blockchain (i.e. the Reach language) as you could understand that you don't want a smart contract logic to be faulty when it comes to handling people/organization money.
All that to say we shouldn't be talking in absolutes in one side or the other. It's a tough challenge for sure but those are not problems without solutions. Many organizations have overcome those already as of today. It may take time for Ford to ramp-up to that level across the board but seeing some movement on some user facing components would probably go a long way in demonstrating their abilities and willingness to continually improve. I'm sure some people over there are working their tails off to get there but organizational changes take time when the sense or urgency to change is not fully realized by the majority.
The Scene of DevOps in the Automotive Industry - DZone DevOps
Embedded DevOps: Implementing CI/CD in Embedded Development (windriver.com)
Tooling for car manufacturers to do DevOps
DevOps for Automotive Companies and OEMs With the JFrog Platform
It's also strange if Daimler is looking to hire DevOps engineers for their embedded systems. Maybe we should reach out to them to let them know it can't be done. Would save them a bunch of money!
DevOps Engineer for Autonomous Driving platform (all genders) - in Berlin| Daimler > Career > Job Search > Job Postings
Side note, I also happened to have found that Ford uses that manage OTA:
Customer Success: FORD MOTOR COMPANY | Wind River
I agree with the above point, which is why I was mentioning that Microsoft and Apple have simplified the testing process for new OS updates by reducing the number of permutations that need to be tested for at least the code they are shipping. All that while each individual components included in that release is continually unit and integrated tested in the overall OS build. External dependencies are something are like any dependency, they are part of the code to ship, so they need to be integration tested at a minimum.There are no such thing as "independent" releases in real life multicomponent multiteam multivendor projects. Not to repeat myself some, but when Windows Update used to ship 10 "independent" patches a month (an average number to make a point), that was 1,024 possible combinations, which became 1,048,576 after two months, and so on. Do you think all those combinations were tested? Of course not. Microsoft has said so publicly. And that was just the OS, not the app layer or all the hardware drivers or... Even in a perfect DevOps pipeline world (which nobody had because nobody develops without outside OSS nowadays and that stuff is never fully tested as independent components nor properly updated), there are still component dependencies. (This is I admit somewhat pedantic because I am focusing on one word perhaps too much.)
To prove that all execution branches in a piece of software have been exercised of that a program logic is sound is difficult for sure but it's definitely a topic of active research. Languages have been developed to tackle that particular challenge, recently in the world of blockchain (i.e. the Reach language) as you could understand that you don't want a smart contract logic to be faulty when it comes to handling people/organization money.
All that to say we shouldn't be talking in absolutes in one side or the other. It's a tough challenge for sure but those are not problems without solutions. Many organizations have overcome those already as of today. It may take time for Ford to ramp-up to that level across the board but seeing some movement on some user facing components would probably go a long way in demonstrating their abilities and willingness to continually improve. I'm sure some people over there are working their tails off to get there but organizational changes take time when the sense or urgency to change is not fully realized by the majority.
Sponsored