Turning embedded programmers into embedded engineers - Embedded.com

Turning embedded programmers into embedded engineers


As noted in this week’s Tech Focus newsletter, a constant theme by several regular contributors to Embedded.com such as Jack Ganssle, Robert Oshana, David Kalinsky, Bruce Douglass and Stephen Mellor is the need for embedded systems developers to think of themselves more as embedded engineers than as embedded programmers. This means, they all agree, adopting tools, techniques and methodologies as sophisticated as those used in many hardware disciplines: greater use of metrics, better tools for generating reliable code, and better ways to integrate hardware and software development.

Along with a number of other lecturers and experts, they will also be part of an Embedded Systems Engineering Track of about 12 classes at ESC/EELive! next week, with up-to-date information and perspective on achieving this goal.

In “Managing Embedded Projects,” Jack Ganssle will provide advice on creating and managing project specifications and expectations and managing bugs to dramatically reduce development time., fixing the feature/schedule/quality conflict, and learning from mistakes and successes. “For all of the talk about technology,” he says, tthere is much too little said about managing the technology and managing the process of bringing an embedded system from concept to production.”

In “Software Performance Engineering,” Rob Oshana will go into detail on how to systematically plan for and predict the performance of the emerging software throughout the development process. “This is important in embedded real-time systems where performance is an explicit, measurable requirement,” he says. “Achieving performance goals is not something you want to think about towards the end of the software development process.”

In “Design Of High Availability Embedded Systems,” David Kalinsky provides a wealth of informaiton on how to design embedded systems with the hardware and software required to continue providing service despite the occurrence of internal and external faults using techniques such as N-plexing, backward error recovery and fault tolerance techniques including checkpoint-rollback.

Several other classes that are among my Editor's Top Picks include:

How Applying Systems Engineering Can Help Avoid Pitfalls,” in which Dwight Blue as systems engineer at TASC Inc. provides his perspective on how the use of systems engineering techniques can provide insight into potential pitfalls during the design phase, potentially rescuing a project otherwise doomed for failure.

Adaptive Requirements Engineering,” by Stephen Mellor in which he details such agile requirements engineering concepts as stories and rationales and how their effective use can be the difference between product success and failure.

Costly Mistakes of Real-Time Software Development” by Dave Stewart, in which he describes common mistakes and pitfalls associated with developing embedded real-time projects; their origin, causes, hidden dangers, and cost as well as how to avoid them.

Embedded.com Site Editor Bernard Cole is also editor of the twice-a-week Embedded.com newsletters as well as a partner in the TechRite Associates editorial services consultancy. He welcomes your feedback. Send an email to , or call 928-525-9087.

See more articles and column like this one on Embedded.com.Sign up for s ubscriptions and newsletters . Copyright © 2014 UBM–All rights reserved.

4 thoughts on “Turning embedded programmers into embedded engineers

  1. “methodologies as sophisticated as those used in many hardware disciplines”

    OK, I'll bite.

    I really struggle to see how hardware engineers have better methodologies than software engineers. How about some concrete examples?

    Hardware engineers

    Log in to Reply
  2. Well, your description of “design…test…tweak until it works” isn't accurate, so maybe you're not seeing 'cuz you don't know the best hw practices. For both logic and analog & sig integrity the process includes validated EM models and sim

    Log in to Reply
  3. I agree with you Nanonical!!! Even with the hardware description languages such as Verilog, VHDL, and SystemC – each of which are based on different software languages (C, Ada and C++) – place much more emphasis on the “engineering” aspects such

    Log in to Reply
  4. Mentor Graphics, Synopsys and Cadence (don't forget them!) have HW/SW co-development platforms involving virtual prototypes of the hardware design, which are interfaced to the software development environment as soon as a minimum viable design is ready to

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.