Innovation in engineering practice and education has been reinvigorated by two complementary concepts: automatic code generation and the inexpensive, open-source, single-board microcontroller. Automatic code generation from system block diagrams has been around for decades, and now is an entrenched way of developing embedded control systems and performing hardware-in-the-loop testing for many aerospace and automotive companies; it is quickly moving into other industries. The Arduino microcontroller has been around since 2005, but quickly has become a favorite for inventors and students.
There is something about computer programming and implementation that seems so out of place in engineering problem solving that very often an engineer relegates it to a specialist. The phrase “engineer programmer” is an oxymoron. I have said that the human, the computer tools (software and hardware), and the problem should all be in perfect harmony throughout the entire problem-solving process. The combination of graphical programming using block diagrams, automatic code generation from the block diagrams, and then implementation on an easily understandable, yet powerful, microcontroller comes close to that ideal.
Honeywell, in 2005, observed that the typical software process injects 100 defects, due to both design and coding errors, per 1,000 lines of source code using manual processes. Manufacturing processes have been automated to achieve six-sigma quality levels, i.e., not more than 3.4 defects per million opportunities. Honeywell has automated the manufacturing of software through the use of automatic code generation and demonstrated the achievement of six-sigma quality.
Northrop-Grumman has fine-tuned the process of going from the desktop directly to flight code on flight hardware. Rapid prototyping and hardware-in-the-loop testing are now the rule, rather than the exception.
What could possibly excite an engineer or engineering student more than solving a real-world problem? Seeing that solution implemented in hardware does that! While teaching model-based design and controls over the past 20 years, I have not seen a more exciting, effective, and accessible problem-solving combination than graphical block-diagram programming, as is done in the MatLab/Simulink environment, along with automatic generation of C code for a microcontroller, as is done using the Arduino microcontroller with the Simulink Coder.
Today, all varieties of robots and self-balancing transporters are conceived, modeled, simulated, controlled, and virtually prototyped before construction in a way that all engineers embrace.
This is an age of diminishing meaningful human interaction. A university engineering program’s value then lies in demonstrating the importance of this interaction through faculty-student mentoring and education in the context of real-world, human-centered, team-based problem solving. The automatic code generation and Arduino microcontroller should be a part of that strategy from the beginning of an engineering student’s career. Innovative concepts, expressed graphically for all to see and understand, automatically become real-time instructions for a computer, and then become real-world actions to make a difference.
Kevin, as one who has done this kind of thing for over 30 years, I can tell you that much of the fun in solving the problem is in writing the code. The reason you see so many microprocessors in products today is that it is cheaper and easier to write and change code than circuits. And don't even get me started on programming analog circuits.
Comparing the number of defects in manufactured hardware to code is not valid. Software and circuit design are equivalent, not software and manufacture. If you look at the equivalent manufacturing process (i.e., reproducing the code for distribution) then software trumps hardware any day. If any errors are introduced it is in the underlying hardware medium it is not in the software. In fact, with checksums used in code distrubution the errors can be detected before the software is ever used and the information re-transmitted.
As for automatic code generation, it is the exception rather than the rule. The companies you mention will use automatic code generation to create a template and to automate the rote communication code that is required. The code that solves the real problem is still done mostly by hand, or hand tuned after some level of generation.
When you are talking about small microprocessors, hand coding is essential. The diagram needed to drive an automated process in many cases is more difficult to draw than just writing the code.
Finally, electronic cirsuits today are developed using code anyway. These are VHDL, Verilog, System Verilog and System C. They are very detailed, much more detailed than writing code for a microprocessor. Once a circuit is developed it is successively transformed using very complex and expensive tools, until it is in a form that can be manufactured. Even with these tools, it takes a good bit of time.
naperlou, I agree. The fun in software development is in hand coding but what's happening today is there's a lot of non-tech entrepreneurs who are creating new tech products. Without spending a lot of detail time reading datasheets or software design guides, Graphical based programming languages that auto generate C-code allow non-tech entrepreneurs to rapidly develop a PoC (Proof of Concept) for feature/function feasiblity. Once the PoC establishes validation of the idea being sound, then the auto generated code can be optimized using traditional hand coding techniques.
Also, to spark interest in electrical-electronics and computer engineering, tools like Matlab/Simulink, NI LabView, and Cypress Semi PSoCs keeps the interest of the next generation technologists and engineers in engaged in the problem solving tasks through a fun-graphical creative learning enviroment. As titled in Michael Schrage's book, its "Serious Play".
Naperlou, I agree with you. I used to work with PLC programmers and their software ladder logic on real-time controls. I'd program PC as the brains and their PLC's were the automonic systems for our systems.
Many times I saw the PLC programmers unable to understand why their scan rates went into the toilet after they added just one more functional block to their programs. Repeatedly I had to tell them that one block contained a massive chunk of code that had to run in order to simulate that function. We'd usually find another set of lighter weight blocks to use instead.
Removing them from the nitty gritty of code creation removed them from reality.
My prefered language was FORTH, that let me do keyhole optimizations by recoding some of the slower high level commands into assembler. FORTH lets you intermix high and low level language constructs as long as they manipulate the stacks in a similar manner.
And you can implement FORTH in less than 8K or memory, perfect for microprocessors.
While I acknowledge the value of these observations (getting more people into engineering) - I have some serious reservations concerning the use of these new "tools" ( graphical programing environments/ auto code generation).
The "other side" of a double sided sword... Easy to create - vs - encouraging people that do not have the basic discipline required to understand a problem - to automate a solution!
I see a parallel with office staff creating custom spread sheets (another simplified programming environment). Most often these "programs" are created without any education on structure/quality assurance or simple verification of proper operation! Result: People making important financial decisions for a company with bad data!
The other concern: efficiency vs creativity. Automation of code creation is like power steering in a car.... a trade off in "road feel" vs " ease". In this example "ease" equates to removal from understanding the problem - resulting in good - but never great - performance.
The last observation: true automation in creating code is VERY different than most the examples given - which are wrappers for code re-use.
I used to program CNC machines awhile back and we did straight coding. A few years after that I ran a machine that was all GUI and just spit out the code. This was a new company for me, and everyone there just excepted the code as fine. Once I was there for awhile and comfortable putting in my opinion I told them the programs this thing gives you are terribly inefficient. As I had learned the code from scratch I could take so many unneccessary lines out of the machine's code it would sometimes cut a parts cycle time over %50 easy.
So I guess my point is...yes this is good...but I feel you should still know the code and not rely on a machine to give it to you...How can you debug or modify code you don't understand anyways?
A Raspberry costs $35, uses an ARM1176JZ-F running at 700Mhz, has Ethernet, 2X USB, HDMI, stereo audio and about 20 GPIO pins. It is the size of a credit card and runs from a cell-phone charger. It also runs debian linux.
It can encode/decode 1080P video, and can handle wireless simply by plugging in a 802.11 - USB "dongle".
And if you don't like linux, you can program the device in ASM, C, Python, etc. A port of Android is in the works.
I think the Pi and the many kits available for it are an excellent platform, but the Arduino also does analog which the Pi does not. so as long as the digital on/off is sufficient then you get more out the Pi.
The Arduino is now used in commercial applications such as toys (e.g. MakeyMakey) and is one option in the endless array of low cost microcontrollers to choose from. The fact that the Pi sold more units does not mean that the Arduino is bad. The Pi can do more things, but does not do everything an Arduino can do. As it turns out, there are Arduino boards that plug straight onto the Pi combining both worlds and more and more companies make good business with both (e.g. Adafruit Industries).
Lastly, Linux is the name of the kernel for the operating system that runs on the Pi. The choice of kernel/OS does not determine which programming language can be used. The Pi is designed to run a Linux distro (Debian) and be programmed using Python (which is why it was called "Pi").
While you have embraced a nice tool set for getting students excited (which has it's value) .. it is based on assumptions in hardware and software that are becoming obsolete!
The raspberry pie / beagle board/ and numerous other new platforms are demonstrating platforms that are very cheap can include enough processing power and memory to compete with the desktop environment. (no need to separate development environment vs target platform in most applications.
My point... Your students should be learning both the macro (trends in industry) AND micro (low level coding) aspects of developing products and the tools available.
Your observations on the trends in the industry (concerning code generation) - are over simplified to the point of being misleading. Similar to some perspectives on "auto-routing" of PCBs.. (Most professionals in the industry use auto-routing features of their pcb CAD software in a VERY limited manner, reason: they can route most sections of a design better manually)
While you may see my observations on newer hardware as a confirmation of your conclusions - I see them as a unintentionally distorted perspective on software development (no offense intended - intended only as constructive critic).
Naperlou is correct... code quality comparisons aren't that simple.
An excellent, free tool that I've used for years is devFlowcharter. You create using a flow chart and the output is in C. The real benefit is coming back years after a project has been completed and easily being able to modify complicated code that would otherwise have been forgotten.
On April 21, NASA launched a novel project, putting into orbit three satellites that employ an off-the-shelf commercial smartphone as the control system.
The legacy endpoint devices that control our critical infrastructure (utility systems, water treatment plants, military networks, industrial control systems, etc.) are some of the most vulnerable devices on the Internet.
In a switched-capacitor filter, capacitors and switches take the place of resistors and accurately reproduce the characteristics of continuous-time Bessel, Butterworth, and elliptical filters.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 5
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
2 
