10 skills embedded engineers need now
Back in the early days of embedded in the 1980s, the guy (and it was mostly guys then) who designed the mixed signal circuits, the guy who connected the microcontroller, the guy who wrote a bunch of low-level assembly code, and the guy who got the prototype out the door—well, it was all the same guy.
One engineer pretty much did it all.
Then, as embedded systems became bigger and more complex—millions of lines of code now ship with devices—embedded skill sets became partitioned by discipline: hardware developer, firmware developer, software developer.
In many big companies that is still the case. But the pendulum appears to be swinging back, as more and more companies are consolidating engineering roles, looking for developers who are fluent in both hardware and software, and trying to accomplish more with less. Certainly a bigger percentage of engineers say they work on both hardware and software, as compared to the group that only does one or the other.
Given that it’s not possible to keep up with everything embedded, how do you make sure that the new skills you acquire are the most relevant?
EE Times turned to nine embedded professionals and a recruiter and asked them to tell us what they think are the most important things engineers should learn now.
Though opinions differed on the specific skills that are most important, they all agreed on one thing all engineers should do: Never stop learning.
Click Next Page to begin the list.
1. Learn the technologies that make the Internet possible.
By and large, if you can do mixed signal design and code in C or C++, you are pretty much good to go in the embedded world. In fact, just knowing how to write code in C or C++ may be enough in many cases.
But I would advocate that learning the technologies that make the Internet possible is a big plus for an engineer’s career. As a matter of fact, I am currently working on several initiatives that involve embedding a “virtual” XML into embedded systems. We are using this technology to allow for autonomous meta-data transaction processing with disparate devices communicating–using different low-level standard and proprietary protocols to affect a network abstraction layer.
I suppose that one can think of this as the “Plug and Play” model for small devices on the Internet.
Source: Ken Wada
Title & Company: President, Aurium Technologies, an independent product design and consulting firm
What I do: I have 30 years experience in the field. Now I architect and design products and systems for various high-tech industries. I am unique in that I’m split between being a generalist and a hardcore theoretical type.
2. You’ve got a search engine. Know how to use it.
Don’t waste your time reinventing the wheel, take advantage of all of the open source stuff that is out there. I suspect that someone else has already written just about any piece of code you could ever want.
There are exceptions, of course, when you’re doing things like bleeding-edge research. But most of us work to solve everyday problems. So take advantage of all of the code and all the brilliant folks available via the Internet.
Don’t sit in your cubbyhole trying to puzzle through the issue (unless that’s your "thing"). You should become a member of the community. Help folks out when you can, and they’ll likely do the same. Open source is a wonderfully powerful tool that only works if people cooperate.
Source: Michael Anderson:
Title & Company: Chief Scientist, The PTR Group
What I do: I’ve been an engineer for 35 years. I describe myself as a software guy who can read schematics. I work on low-level development primarily–porting operating systems, device drivers, kernel-level work, etc. That understanding now helps me as a systems architect who can see how a whole project fits together.
Next; step outside your comfort zone…
3. Learn something new outside of your comfort zone.
Although spending some time chasing the latest fad is useful and fun, the biggest benefits come from either deepening or expanding your domain of expertise. Challenge yourself to learn something outside your comfort zone such as hardware, your company’s or customers’ domain expertise, or project management.
At the same time, focus on improving your fundamental skills and inherent strengths. Work hard to develop a political sense that will help you understand the motivations of the people around you. Engineering is fundamentally a human endeavor, and the key is to maintain that balance. Too many young engineers focus too heavily on people or too heavily on engineering. I know that it is not easy, but you really benefit by working on both sets of skills.
Source: Matt Liberty
Title & Company: Founder of Jetperch LLC, a company that provides DSP and embedded software consulting services
What I do: I’ve been an engineer for 18 years. I think of myself as a generalist who understands the business of engineering and systems engineering while still being skilled at embedded software and DSP algorithm development.
4. Become experienced with a real time operating system.
Engineers who learn a formal structured development processes while working with a real time operating system (RTOS) are in high demand today and command bigger salaries. That’s because they have acquired the necessary discipline to develop any kind of safety critical product and they also understand the idea of concurrency: Given that at any given point the CPU can be called to run a different task, they know how to make sure that the resource they are currently using is not going to be trampled on. In short, they know how to protect resources from other tasks using the service unexpectedly, while maintaining performance.
So I would encourage engineers who are working with smaller devices who have not worked with an RTOS to get some hands-on development experience–whether it’s VxWorks or Green Hills INTEGRITY or Micrium’s μC/OS. I am also starting to see a call for a lot of embedded Linux. That’s because Linux (in general) is a very scalable operating system. You can strip it down to the bare operation for timing and scheduling and then load it on to whatever hardware you want and do kernel development for greater optimization and control.
Source: Henry Wintz
Title & Company: Solutions Manager for the Embedded Industry Practice at Randstad Technologies, an engineering and employment hiring services firm
What I do: Simply put, I’m in the business of making things happen.
5. Diversify your skills and move up the stack.
If you are still working barebones or on smaller MCUs, I advise taking a Linux driver class. It will make it easier to move to Android later. And—although there is possibly less value–if you are used to working on large systems, try working barebones.
Move up the stack: Make a mobile app or learn some back-end server stuff. It will give you a new vocabulary and perspective.
And become familiar with open source hardware. The projects I did 8 years ago required me to spin my own HW and so on, so I could not focus on the algorithm development. Today, there are plenty of off-the-shelf boards that allow me to focus on the hard, unique stuff.
Sure, it can make me feel like my whole existence of firmware has been nullified and in many ways the fun of board bring up has been taken away from me, but sometimes, we have to focus on the end game. Unfortunately, this means I meet fewer and fewer people with those particular skills, and those who do are literally a dying breed.
Source: Jen Costillo
Title & Company: Consultant, Rebelbot
What I do: I’ve been an engineer for almost 20 years. I consider myself a jack-of-all-trades, in that I have experience in so many different areas. I’ve worked as low as a circuit designer and as high as making apps on Android or Windows. I’ve also worked in broad tech support and as an R&D engineer.
6. Know your software well but always tinker with the newest processors.
It is good to know a few languages, some people recommend learning one new language a year. However, while pure software engineers need to learn languages to fit specific needs, embedded engineers need to learn chips. A deep understanding of C or C++ is critical but the newest trendy language is not as important as the newest, trendy processor technology.
It’s important to know about processors, that’s just the nature of embedded. Because we have resource-limited systems, we need to understand those resources we have available. A new and nifty language like Go might be incredibly powerful, but it’s very likely that it doesn’t run in our resource-limited environment.
In the end, you should acquire lots of shallow breadth and a few areas of deep depth. Keeping current is important but learning all you can about a few areas makes you an expert.
Source: Elecia White
Title & Company: Embedded Software Engineer, Embedded.fm
What I do: I have been an embedded software engineer for over 15 years. I did normal (server) software before. I’ve done some management over the years but I enjoy the hands-on technical aspects more.
Next; Get on board with open-source…
7. Get comfortable with open source software.
There are literally thousands of software packages that customers want integrated into their systems, so this is an area where all embedded engineers need to feel comfortable.
I would also stress that you should avoid pigeonholing yourself into one area, as the skills you have will almost inevitably become obsolete and/or prevent growth.
And make sure that you understand both hardware and software; engineers who know both are the most valuable.
Source: Rob Oshana
Title & Company: Distinguished Member of Technical Staff and Director of Global Software R&D for Digital Networking, Freescale Semiconductor
What I do: I have been an engineer for 31 years. I was educated as a EE, but I have been doing software engineering most of my career.
8. Develop a systems engineering mindset.
It’s critical for embedded engineers to have a systems orientation. I have seen a number of projects suffer because things like a clear defined requirement baseline, verification strategy and a plan for demonstrating compliance was not considered early enough in the project. And every engineer should acquire good project management skills as you will be asked to commit to achieving deadlines. Having the ability to sensibly explain the risk in terms of technical and project risk will serve you well in your career.
Source: Adam Taylor
Title & Company: Chief Engineer Electrical Systems, E2V
What I do: I have been an engineer for 15 years. If I had to pigeonhole myself I would say that I am a high-reliability embedded system specialist. However, I have been very lucky in my career and have had the opportunity to design for a number of applications.
Next; Communications means human-human, too…
9. Become skilled at expressing yourself (both in words and graphics).
Engineers of all types need to be able to effectively express thoughts and ideas and often the best way to do that is graphically. Too often I have asked junior engineers to explain a concept, only to cringe as they ramble on without being able to focus on exactly what it is that they are trying to explain.
We used to use flow charts to explain concepts. Maybe those are somewhat obsolete today, but every engineer should have as a fundamental skill the ability to use block diagrams, state machine diagrams, pictures or clouds or light boxes or whatever tool can aid in conveying concepts. Particularly if they are trying to explain how something works.
Can you imagine trying to explain to a developer who is writing the software for a controller how the machine works using a text-based document?
Mindmapping is one of my favorite techniques for capturing and visually organizing my idea and thoughts. I use iThoughts, a mindmapping app for the iPad, almost every day.
Source: Jean LaBrosse
Title & Company: President, Micrum
What I do: I am an EE by training and I have a masters in computer science. As an engineer, I like to look at things that are complicated and simplify them.
10. Learn wireless connectivity.
The one thing I would recommend embedded engineers learn in the next 1-3 years is wireless connectivity, specifically WiFi and/or Bluetooth low energy (BLE).
The primary (and sometimes only) way to interact with embedded devices is moving to the end user’s smart phones, at least in consumer electronics. Consumer electronics companies know that a smart phone is a much better user experience than most embedded systems can hope to provide on their own. And other industries and product categories are figuring it out too.
Our embedded systems are going to need to to talk to an app on a smart phone or an internet-based service in order to do anything – communicate with the user, get firmware updates, troubleshoot problems, etc.
It might be going a bit too far to say that WiFi and BLE will soon be as common as the UART is today, but it’s not too far fetched, and it’s a good tool to have in your toolbox.
Source: Chris Svec
Title & Company: Senior Principal Software Engineer, iRobot
What I do: I’ve been an engineer for 13 years. I think of myself as a “low level” embedded engineer. I like living at the hardware/software interface. But I’m also a “big picture” kind of guy, which means that I need to understand the full context of the product I’m working on to really enjoy my work.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
