Comment Standards & cheaper hardware are game changers (Score 1) 266
As an example, and with its own problems, the Raspberry Pi has proved "good enough" for a lot of embedded companies, who just accept various tradeoffs to code in Python (or whatever) under Linux. In ten years, such hardware will be even cheaper and even better, and may have even better RTOS support:
http://pebblebay.com/raspberry...
Likewise and even more so for the truly free and open source Beagleboard family:
http://beagleboard.org/
What a far cry from the Kim-1 with 1K of memory I bought as a kid (with my father's help) for probably 50X in current dollars what a Rapsberry Pi or Beagleboard costs and supplies about 1GB memory. We even had to build the power supply ourselves.
This is not to disagree with what you are saying right now. I know how hard and important all that work can be. But if better tools eventually let fewer engineers produce more projects in the same time, and cheaper hardware means less constraints, and other standards change expectations so customers know to work within them, than the need for managing such complexity (including the human side) may go down. Granted with a rising increase in an internet of things and robotics, embedded work may well still increase in demand for a decade or two until better standards come to dominate the field and change the nature of so many embedded tasks. So, for anyone already well enmeshed int he embedded field, it may well be a good gig for the next decade or two.
Anyway, for fun, to go through your list (a bit tongue in cheek, so not completely serous answers):
"First of all the robot would have to sit in meetings with the customer understanding what the customer wants, telling him what can't be done and outlining alternative solutions in dumbed down language the customer understands. It should tell the customer if some of his choices will raise the cost (Yes, in theory the hardware can do X but the current drivers can't)."
This can be replaced in part by a web interface where the customer clicks on options and the software tells them if the combination is allowed.
"It would have to write an offer listing everything that the customer wants to have implemented but worded so he can't expect more for his money. It has to be worded so that sales people and management understand enough to agree to the price written at the bottom."
Again, web backend generates this based on web interface choices.
"It needs to understand all documentation provided by the customer and it needs to be able to find more. It also needs to know who it can ask for an undocumented detail. Currently documentation includes data sheets, Doxygen like API descriptions, articles, standards, schematics, forum discussions, RCS commit messages, source code, and books but there will probably be a new form designed to be understood by machines. It is also useful to remember everything the customer said even if it might turn out to be wrong."
This could be mostly replaced by machine-readable standards as you suggest.
"It has to know sources of errors. Documentation can have errors. There can be errors in the design of the hardware. The hardware might be faulty (f.ex. bad solder joints) and you need to know what will destroy the hardware (no you can't configure that GPIO to output a low value). It has to fix simple errors itself (yes, I did have to solder some jumper wires and pull up resistors in the past few years). If it can't fix the error, it has to discuss the problem with someone who can. If the problem won't be fixed (no we won't spin a new SoC revision for you) software workarounds have to be devised and the pros and cons have to be discussed with the customer. To be able to find errors, it has to know about software and hardware debugging techniques (printf debugging, Gdb, Valgrind, JTAG, oscilloscope probing,
Bad hardware becomes so cheap it is discarded. Twenty years ago OTI had embedded Smalltalk development tools that could make such debugging much easier. See:
http://www.slideshare.net/esug...
"It has to write code in a form that can be maintained. It has to merge code (complete components and updates thereof) from suppliers and know what has to be changed to make it work again. Our suppliers often don't know they are supplying to us, so is has to have an eye on their release and security announcements. It has to decide if an update is advised and then has to inform the customers (if they signed a support contract)."
Again, Smalltalk was the answer. It might be yet again someday.
"It has to come up with software tests. Some customers explicitly want unit tests or detailed test reports. It has to do the tests that have been paid for. Of course the minimum testing is determined by what makes you feel confident that it works."
Yeah testing can be hard. But that's what unpaid exploitable interns trying to break into the industry so they won't starve are for.
http://theintern.io/
"It has to write documentation. Test reports, end user documentation, API descriptions."
The new standard is that the need for documentation is an error that needs to be routed around.
"It has to communicate with the customer to ask for things that have to be provided (We need a cable for your special connector on port X. When can we expect the display PCB to be done?), to learn about bugs and to announce releases. Doing so it has to be polite. It must be pleasant for the customer to communicate with the robot."
This is all handled by an Amazon-like web site.
"It has to meet with the customer for an integration workshop (Our first board revision will be assembled on Thursday. Can you come on Friday to make the software work? Yes, we know it did work on the evaluation board.) or to analyze bugs on size (Our factory stops working about a handful of times a day. No we can't send it to you and we won't connect it to the internet for debugging.)."
The web site is always available. The hardware downloads the updates itself wirelessly using some standard protocol.
"There is probably still something I forgot. In my opinion it would be inefficient to split all this between humans an robots. How would a human know what is possible if it doesn't do the coding? Given all that, I think my job is safe until machines are intelligent enough to rule the world."
Better tools will help fewer engineers do more. But I agree embedded engineering is one of the most important jobs in our society right now and the need will grow. However, in the same way engineers rarely solder individual transistors into logic circuits theses days, in the future, engineers may be working with large building blocks and better tools for integrating them. That also could just printing out a perfect (and self-testing) design based on simulation tests using standard building blocks. It is when we push the edges of things that we have the most issues to handle. As hardware and standards improve, the edges may get farther and farther away.