Martin Heller
Contributing Writer

Embedded Does Not Mean Small

analysis
Sep 19, 20072 mins

I spent the day in Boston yesterday at the the Embedded System Conference. I was supposed to go back today, but I'm a bit under the weather, so I'm staying in my office. I worked on embedded systems years ago: those were the days when what you could expect for a processor in an embedded system was an 8051 or maybe a 6802. Back when I was an accelerator Physicist, the electrical engineers and I retrofitted an iso

I spent the day in Boston yesterday at the the Embedded System Conference. I was supposed to go back today, but I’m a bit under the weather, so I’m staying in my office.

I worked on embedded systems years ago: those were the days when what you could expect for a processor in an embedded system was an 8051 or maybe a 6802. Back when I was an accelerator Physicist, the electrical engineers and I retrofitted an isotope-production cyclotron with 6802-based stepping motor controllers; the motors attached to the cyclotron’s tuning dials, and the boards had serial interfaces to a PDP-11, which monitored the cyclotron and ran a program that attempted to keep the cyclotron tuned properly via the controller boards.

I knew then at the gut level that an embedded system did not imply a small system: those cyclotrons occupied 1000-square-foot concrete vaults, drew kilowatts of power, and put a concentrated beam of protons on a target. I also knew at a gut level that reliability can be critical in an embedded system, and that embedded systems often have hard real-time constraints.

The “embedded does not mean small” message came home to me again yesterday. So did the reliability message.

When you think of embedded systems, cell phone handsets may come to mind. From a software engineer’s point of view, however, cars are embedded systems, and so are telephone PBX systems, and airplanes.

These days, an automobile typically has many control units, all networked together over one or more busses. Automotive engineers use a bunch of standards — they have as long as I can remember — but now many of their standards seem to be related to their embedded computer software and the interfaces to the control units.

Think about telecom again: the software for a big telephone switch is massively parallel and can easily amount to 10’s of millions of lines of code. If the switch handles, say, all the 911 traffic for the East Coast, perhaps its reliability matters just a teeny bit. How are you going to guarantee that reliability?

Martin Heller

Martin Heller is a contributing writer at InfoWorld. Formerly a web and Windows programming consultant, he developed databases, software, and websites from his office in Andover, Massachusetts, from 1986 to 2010. From 2010 to August of 2012, Martin was vice president of technology and education at Alpha Software. From March 2013 to January 2014, he was chairman of Tubifi, maker of a cloud-based video editor, having previously served as CEO.

Martin is the author or co-author of nearly a dozen PC software packages and half a dozen Web applications. He is also the author of several books on Windows programming. As a consultant, Martin has worked with companies of all sizes to design, develop, improve, and/or debug Windows, web, and database applications, and has performed strategic business consulting for high-tech corporations ranging from tiny to Fortune 100 and from local to multinational.

Martin’s specialties include programming languages C++, Python, C#, JavaScript, and SQL, and databases PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database, Google Cloud Spanner, CockroachDB, MongoDB, Cassandra, and Couchbase. He writes about software development, data management, analytics, AI, and machine learning, contributing technology analyses, explainers, how-to articles, and hands-on reviews of software development tools, data platforms, AI models, machine learning libraries, and much more.

More from this author