Author Topic: Drawbacks when working on automotive firmware development?  (Read 1915 times)

0 Members and 1 Guest are viewing this topic.

Offline ace1903Topic starter

  • Regular Contributor
  • *
  • Posts: 237
  • Country: mk
Drawbacks when working on automotive firmware development?
« on: November 15, 2021, 01:43:07 pm »
I apologize if subject is unclear. English is not my native language and know that better words are needed for my question.

Lately I am getting job offerings to work on development on automotive firmware as contractor. Although my many years experience on firmware development, this area is new for me.
I wanted to ask if someone has experience working on automotive to share it here.
I prepared like summary of pros and cons when working on automotive. Maybe there are some my misconceptions and I would like someone with experience to prove it wrong.
Pros:
1) Requirements are well defined and known upfront. No stupid request like IOT battery powered artificial network device that needs to work on single AAA battery 10 years.
2) Defined workflow. Requirement specification, software architecture design, codding, code reviews and good QA testing with no skipping steps.
3) Hardware is designed by professionals and well tested. No endless debugging to find out that power supply causes glitches in software
4) Automatics tests and code coverage tests prevents single change to break whole firmware. 
Cons:
1) Job looks boring. Looking at single software module for years each day.
2) Automatic counting of LOC produced each day adds stress
3) Everyone wants internet gateway nowadays with API that is limited and not to break existing software.
4) Knowledge is kept at company core and it is difficult to learn something that will be valuable outside that sector.
5) Part that is given to contractors most often is headers exported from Autosar and single doc file. One can work for years not knowing how whole software works.

Everyone is welcomed to comment and share experience.   
 
 

Offline Mecanix

  • Frequent Contributor
  • **
  • Posts: 269
  • Country: cc
Re: Drawbacks when working on automotive firmware development?
« Reply #1 on: November 15, 2021, 02:03:23 pm »
The position may be interesting if you are given the role where innovation is key to performance and corporate competition (aka incentives).
Neural networks powered automotive and systems comes to mind.. for instance.

Conventional transistor firmware'ing is getting pretty redundant in this sector, to my limited knowledge?
 
 

Offline ace1903Topic starter

  • Regular Contributor
  • *
  • Posts: 237
  • Country: mk
Re: Drawbacks when working on automotive firmware development?
« Reply #2 on: November 15, 2021, 09:01:09 pm »
I am little bit disappointed because I expected experts from Continental, Bosch, Aptiv, ZF, ThyssenKropp to say anonymously  a word or two 
abut what they like or dislike in their everyday jobs.
Conventional transistor firmware I think it is on top notch now since this semiconductor shortage. Seems quick replacement firmware is needed for the chips that are available instead of that were used.
Neural networks are fine but wondering how much of that code can be made MISRA compatible and under ISO26262.
 

Offline Mecanix

  • Frequent Contributor
  • **
  • Posts: 269
  • Country: cc
Re: Drawbacks when working on automotive firmware development?
« Reply #3 on: November 15, 2021, 10:54:28 pm »
Highest concentration of automotive sector's M.E & E.E. are on the Siemens forums. Transport, aviation, aerospace too...
May or may not be in line with the topic directly (product specific forums) however these folks could give you hints RE trending innovations in the making. Reasoning; see if that matches your job offer's objectives long term-wise and decide then.

e.g.
https://blogs.sw.siemens.com/thought-leadership/2021/10/19/automotive-industry-and-the-impact-of-covid-the-future-car-on-e-e-systems-ep-2-transcript/

ps note the conclusion where it reads "...Automotive E/E Systems Revolution".
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8275
Re: Drawbacks when working on automotive firmware development?
« Reply #4 on: November 16, 2021, 04:48:25 am »
2) Automatic counting of LOC produced each day adds stress
They still do that? I've heard horror stories about how companies did that a long time ago, and it resulted in awful bloated code.
 

Offline coppercone2

  • Super Contributor
  • ***
  • Posts: 9449
  • Country: us
  • $
Re: Drawbacks when working on automotive firmware development?
« Reply #5 on: November 16, 2021, 05:37:33 am »
hmm.. ACTUALLY you get a lithium ion coin cell for the first one

thats likely a real request based on real expectations today. it also sounds like its gonna flop too
 

Online bdunham7

  • Super Contributor
  • ***
  • Posts: 7856
  • Country: us
Re: Drawbacks when working on automotive firmware development?
« Reply #6 on: November 16, 2021, 05:52:02 am »
hmm.. ACTUALLY you get a lithium ion coin cell for the first one

And then you take it out  in v0.2 during the thrifting stage...

A 3.5 digit 4.5 digit 5 digit 5.5 digit 6.5 digit 7.5 digit DMM is good enough for most people.
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3461
  • Country: it
Re: Drawbacks when working on automotive firmware development?
« Reply #7 on: November 16, 2021, 06:57:24 am »
3) Everyone wants internet gateway nowadays with API that is limited and not to break existing software.

I suspect that would be for diagnostic over ethernet, most new cars use ethernet for REAL diagnostic (you log into a webserver hosted in the ECU of course) and keep OBD over canbus for legacy reasons, but i haven't dug into that area yet
 

Offline VK3DRB

  • Super Contributor
  • ***
  • Posts: 2252
  • Country: au
Re: Drawbacks when working on automotive firmware development?
« Reply #8 on: November 16, 2021, 07:40:32 am »
In 2005-2006, I worked developing robots for a major automotive electronics company in Australia. Great technical job, never boring, mediocre management, lousy pay and long hours, so I left.

Since then I had a job for six years where part of the job was coding for a complex safety critical system (not automotive). I was trained to use Simulink (runs on top of Matlab). Simulink is a fabulous tool for real-time applications that are "bug free". I actually designed the entire system in firmware prior to developing the hardware. You can thoroughly test the code in an RTOS, prior to deploying it on a MCU. I wrote a GUI and C wrapper around the state machine so we could model the final product, and it was used for marketing and others to fine tune the requirements. I really enjoyed that project! Never boring. And you get to test your skills with control theory and state machine design. Unfortunately in Australia few companies use Simulink which is a shame considering the development time it can save.

Only negative about Simulink is it is VERY expensive once you get all the add-ons. If I recall it cost us $30K for one license in the early 2000's with some add-ons and a few MCU targets we needed. I believe the big aeroplane manufacturing companies and European auto makers tend to use Simulink because there is no room for error. If the new job allows you to use Simulink, that's a big plus, IMO.
 

Offline BBBbbb

  • Supporter
  • ****
  • Posts: 289
  • Country: nl
Re: Drawbacks when working on automotive firmware development?
« Reply #9 on: November 16, 2021, 08:29:14 am »
1) Requirements are well defined and known upfront. No stupid request like IOT battery powered artificial network device that needs to work on single AAA battery 10 years.
Hmm... well defined - depends what's your benchmark, but for sure it would be better than most outsourced jobs you run at. But don't expect everything to be clearly defined. It depends on the project and OEM customer (there are differences between OEMs in Asia and Europe for example).

2) Defined workflow. Requirement specification, software architecture design, codding, code reviews and good QA testing with no skipping steps.

Related to the upper Q, and answer basically the same. Automotive companies (Tier 1 suppliers) are huge and tasks per teams vary. You could be stuck at a maintenance project, with low knowledge and support from the original team, bypassing the architecture just to make a quick fix for a bug report, w/o fully understanding the system, or you could be working directly with the whole team and the OEM on designing something new, really varies a lot, and I'd say a lot of it is up to you. Some ppl are happy stuck on maintenance projects with low expectations and don't like the spotlight stress on "advanced" projects.

3) Hardware is designed by professionals and well tested. No endless debugging to find out that power supply causes glitches in software
Well yes, usually this is at a higher level then generally, but mistakes happen anywhere, some that sound really stupid, just don't expect perfection.

4) Automatics tests and code coverage tests prevents single change to break whole firmware.
ughhh NO
Code coverage is mostly bullshit as a metric, as a side goal not so much if tests are written properly, but too many times coverage becomes the main goal to satisfy KPIs that it is in the end useless.
And there is no way you can catch everything, bugs will slip in. OTOH there are a lot of stages of testing (oh and this can vary from OEM to OEM) and bugs are caught at higher % before reaching production.


Cons:
1) Job looks boring. Looking at single software module for years each day.
Depends where you end up. not sure how much say externals hold, but generally if you're willing to put in work and you are interested in, you can move to another team where that might not be the case

2) Automatic counting of LOC produced each day adds stress
why would anyone do this? I once spent 4 weeks of very very intense work just to add 2 lines of code, but there were a lot of things to consider and check before adding them, and I was actually congratulated on this.
Counting (E)LOCs sound generally stupid, and especially in embedded environment.

3) Everyone wants internet gateway nowadays with API that is limited and not to break existing software.
4) Knowledge is kept at company core and it is difficult to learn something that will be valuable outside that sector.
VPNs and stuff are normal for big systems. Projects' data is not openly shared, it's per need to know basis for most people. They want to minimize risk of leaks that could hurt the company. A leak of a BCM code into the wild can do a lot of damage to their relationship with the OEMs. There are a lot of precautionary measures to prevent loss of information or prototypes.
You can get people to more openly share project info with you, but it takes time to build trust and you need to be adding value to projects if data is shared with you.

5) Part that is given to contractors most often is headers exported from Autosar and single doc file. One can work for years not knowing how whole software works.
Well this might be true. you never know if you don't try. I would expect that it would loot like this from your PoV in the beginning. Try to talk in more details about what you would be working on.
 
The following users thanked this post: ace1903

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9950
  • Country: nz
Re: Drawbacks when working on automotive firmware development?
« Reply #10 on: November 16, 2021, 09:46:30 am »
Pros:
...
Cons:
...

All of your pro's and con's apply to the company, not the industry.

You will find some automotive jobs which are very ordered and methodical and other automotive jobs that are a total mess.

Greek letter 'Psi' (not Pounds per Square Inch)
 
The following users thanked this post: mfro

Offline ace1903Topic starter

  • Regular Contributor
  • *
  • Posts: 237
  • Country: mk
Re: Drawbacks when working on automotive firmware development?
« Reply #11 on: November 16, 2021, 10:45:33 am »
My pros and cons are just a guesses. Maybe they are more related to companies than the industries.
From my personal experience in telecom industry, it is difficult to sustain state of total mess and be still present on the market.
Each software patch before merging to main tree was first reviewed by colleague then firmware build was tested by dedicated QA team and finally approved by software architect.
Yes, bug can slip once per month but it was rather difficult since each line was read and approved by at least two experienced software developers other than  a creator.
Whole process was taken seriously and accompanied by proper tools. No one wants critical bug on 20+ millions of devices deployed all over the word.
I think that in automotive, telecom, medical industry  such workflow is a standard. Don't want to believe that there are companies that are working in for example medical area that allow total mess.

I am asking here since on job interviews sometimes employer is not completely honest, especially when they are in outsourcing company.
They will say that you will work with newest technology and R&D like job, but on first day you will be given some 30 years old perl code that no one understand but somehow it is critical to work on windows 11 ASAP.
 

Offline BBBbbb

  • Supporter
  • ****
  • Posts: 289
  • Country: nl
Re: Drawbacks when working on automotive firmware development?
« Reply #12 on: November 16, 2021, 11:41:04 am »
Recalls cost a lot of money, thus the more rigorous validation process.
OTOH with OTA becoming a common option there is a bit of a relaxation noticeable with OEMs and suppliers in automotive.

Medical is more extreme, any change triggers too many procedures for approval, and the volume of sold devices rarely justifies those costs. Unless your device is sold in large quantities or is a source of reoccurring income (consumables or real mandatory maintenance)  in US FDA procedure usually eats up the ROI, so the device doesn't even get registered.
EU has better access to medical tech compared to US for this reason.

 
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7388
  • Country: nl
  • Current job: ATEX product design
Re: Drawbacks when working on automotive firmware development?
« Reply #13 on: November 16, 2021, 11:54:34 am »
If you want a job, where you get to wear a tie, have a cubicle and go to work every day, automotive is great.
If you want to have a career, work on interesting projects, do something meaningful, go somewhere else.
 

Offline RJSV

  • Super Contributor
  • ***
  • Posts: 2121
  • Country: us
Re: Drawbacks when working on automotive firmware development?
« Reply #14 on: November 26, 2021, 04:16:59 am »
(Can I call you 'Ace'?)
   Ace:
   I wrote firmware from other perspective, the scanner,
for American auto market, which, as you know, has a mix of global manufacturers.
   Interesting, as we NEVER discussed any spec. like ISO2626...(Barely heard of it). So that's a thought, as even while safety issues might be lessend safety and reliability have GOT to impact (no pun) longer term profitability for any company.
   But, back to your questions, it seems like you maybe have various generic employment reactions and opinions. But, funny, let's wait and see, on that LOC dynamic: How many software folks, here, are going to praise that (ridiculous) lines of code metric. Prob 0.

   For your more generic questions, any industry history will have wisdom for you. Specific to automotive, that's a real dynamic world. Be all changed, majorly by 2030, I'll bet...
   If you can upgrade expertise, with neural nets might be one step. What kind of annual 'shows' are there, for tradespeople to consider the future (market)?

   The more generic career questions, have answers more related to politics (ugg) and that's makes for TWO squirrely and quick moving trends.
   I did notice, you communicate a fairly advanced grasp of the science, there. Any prospects doing some teaching, locally, at a university?
Of course, that might make an employer nervous, if you doing some moonlight / second job.

   Oh, and by the way, a lot of nasty office settings, and rules come out of small, private operations, while the bigger places tend to have more 'waste' and procedural or 'bureaucratic' nonsense, like LOC so, again it seems you are thinking like a lot of working people.
   Personally, I hated the small business environment more, they get lazy about things...like fairness...
When the bosses' son's wife gets a cushy job, corner office, and you BEGGING for air conditioning, things like that.
   I wish you could teach me, I could use an upgrade, in career development, in using various firmware dev tools.
-- Rick B.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9890
  • Country: us
Re: Drawbacks when working on automotive firmware development?
« Reply #15 on: November 26, 2021, 05:05:25 pm »
Only negative about Simulink is it is VERY expensive once you get all the add-ons. If I recall it cost us $30K for one license in the early 2000's with some add-ons and a few MCU targets we needed. I believe the big aeroplane manufacturing companies and European auto makers tend to use Simulink because there is no room for error. If the new job allows you to use Simulink, that's a big plus, IMO.
The personal license for Simulink is reasonable and I have had it for a three or four years.  I can't use it for other than personal projects but I'm retired, it's all personal.

I rather enjoy modeling analog computer type problems and watching them run.  I can plunk down integrators and summers all over the place and just wire them up.  Simulink is a great tool!

I have several add-ons in addition to MATLAB itself so my annual subscription is still a couple of hundred dollars. I am not obligated to keep a subscription but it does keep me current.  Great tools!

 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9890
  • Country: us
Re: Drawbacks when working on automotive firmware development?
« Reply #16 on: November 27, 2021, 12:48:04 am »
Paul Simon had a song about leaving a lover that has a lot of parallels in leaving a job:

https://youtu.be/K4xoHjNjxus
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf