Wednesday, August 29, 2012

Designing a Robust Communication Protocol

In today's world of designing distributed embedded systems, it is imperative to design, document and test the communication protocol early on.

I recommend building upon the layers of protocol provided by the underlying architecture you have chosen, for example, TCP/IP, Bluetooth, USB, etc. If the underlying communication layer provides data integrity and delivery then it should not be duplicated in the application portion of the communication protocol. At a minimum, you are looking to have a low-level handshake between subsystems with assured delivery. Consider the following questions:

  • Does the packet need to be routed?

  • Does the sender need to know that the recipient received the communication packet?

  • Is the data intact?

Now you can move to the business logic portion of the packet--the data payload definition--and begin to address these questions:

  • Is there a command/response requirement?

  • What is the general packet definition?

  • Are there different types of packets?

  • Is the packet size variable- or fixed-length?

  • What are the physical units of the data transmitted?

  • Was the packet understood by the receiving subsystem?

In addition to these questions, it's imperative that you list all of the possible error conditions. Ask yourself how you will be able to make them happen so you can test for robustness, which sometimes requires writing test applications to intentionally insert error conditions. Sometimes an external communication test device is the best choice.

There are many factors to consider, and this brief writeup is simply a starting point. What issues do you think are most important in building a robust communication mechanism?


Wednesday, August 22, 2012

How Managers and Engineers Tackle Projects Differently

They say you can’t understand someone’s perspective until you’ve walked a mile in their shoes. Having been both a developer and a manager it’s interesting how the goals, desires and pressures on each differ. Ideally this wouldn’t be the case, but reality doesn’t always match up.

As a developer I always wanted to create the best work possible. If I could use cool new technologies and learn something in the process, even better. I took pride in the products we created, but was more focused on improving my skills and growing as a developer.

As a manager (and I noticed this more as I advanced more) I was focused on balancing competing priorities from customers (internal and external), delivering results as cheaply and quickly as possible, without sacrificing quality, of course, and shielding my development team from all the stuff that makes them less productive.

At times these differences caused conflict. Maybe trying a cool new untested technology is not the best business decision when you need to get something out quickly. Sometimes there was an opportunity to stretch one of your teams with an assignment, sometimes not.

Differing pressures are always going to cause conflict, but with a good dose of mutual trust and understanding they don’t have to be disruptive. As a manager I always tried to do my best to make sure my developers knew that I knew where they were coming from, and then tried to explain where I was coming from--and mostly it seemed to work.

What experiences have you had in this area?  I’d love to hear.


Wednesday, August 15, 2012

Curiosity Rover -- A Technology Powerhouse

I would be remiss if I failed to mention the biggest technology achievement of this year, the perfect landing and immediate operation of NASA's Mars rover Curiosity. In this stunning achievement of application of modern technologies, I want to point out this fine example of an embedded system.

Spaceflight Now has an excellent article on how the computer system was selected and built to work in the harsh Martian environment. Engineers at BAE Systems chose redundant and radiation-hardened PowerPC electronics to survive the thin Martian atmosphere. With 20% the CPU power of a modern smartphone, this device needs to be able to autonomously roam the surface for extended periods and be capable of sophisticated scientific experimentation.

It is interesting to note that there was not enough memory to store the landing software and the navigation software in the computer's memory. For the trip from Earth to Mars it had one mission, a perfect landing. Once the rover successfully landed and performed basic diagnostics the program memory was wiped and is currently being updated with navigation-oriented software. The new software needs to work flawlessly for a 2-year mission. There will undoubtedly be more updates but not a complete change of function.

For those interested in following its journey, visit NASA's official Curiosity website.


Wednesday, August 8, 2012

How Process Improvement is Like Golf

Every time I’ve taken group golf lessons, the pro has started from the grip and gone through stance, swing and the whole works, laying out his best generic way to hit the ball. I recently learned of a golf school that prides themselves on the fact that they start where you are and help you improve the game you’ve already got. I love this!

This is the same approach I find most successful in process improvement work.  Every developer, engineer and organization has things they do well--and, as I firmly believe, if it ain’t broke, don’t fix it. Every organization has pieces of a process, which may not be ideal, but usually suffice for the time-being.

The key to keeping focus and gaining momentum in process improvement initiatives is finding those key leverage points that can make the biggest difference and leaving the rest for later. A golfer can only keep so many tips in their head, and a development organization can only change so many things at once without destroying their productivity.

Thanks for continuing to read. I love getting your comments back. If you have any suggestions for future topics, send them along, and I’ll do my best to cover them.


Wednesday, August 1, 2012

Selecting an RTOS

Users searching for a real-time operating system (RTOS) for their project often get overwhelmed by the variety of commercial RTOSs available today. This variety nearly guarantees that an ideal system exists for you, but you finding it is a different question.

Embedded Computing Design published a helpful article about selecting an RTOS (this article was published a couple of years ago but the information is still relevant). An important note is that the article is written for selecting an RTOS for medical equipment requiring a high degree of safety and reliability. However, these are factors that should be considered for all embedded design applications, not just medical equipment.

One very important factor that the article does not discuss is RTOS cost. It becomes a complex decision when overall cost to develop the application is balanced against the direct cost of purchasing an RTOS. One needs to consider the initial cost to purchase the RTOS, per CPU license cost, associated third-party library cost with potential to save by reducing development and maintenance costs.

Check out the article and tell me what you think. I'll include your thoughts in a future newsletter.