serv@Route495Software.com
Reusable software
Richard B. Johnson
Many years ago if you wanted to design something that used a microprocessor, you pretty much had to use some standard package provided by a vendor who had specialized software specific for that processor. You would use a non-standard interface to generate non-standard code to do the non-standard things that your product needed to do.
Upgrade
If you were to upgrade your product to use a different processor, you would start all over again. The typical product lifetime of a processor-based piece of equipment is three years, and the typical software development cycle may exceed a year. If you were trying to keep three products in the manufacturing pipeline, this would require the undivided attention of a dedicated software engineer just to keep up.
POSIX to the rescue
Every software based product requires a basic set of code plus some special code that uniquely defines your product. Most of the unique code consists of drivers and some product-specific routines. Everything else duplicates what has already been done for previous products. To help prevent duplication, a set of rules has been developed by the software community. It’s called POSIX (Portable Operating System Interface). Once code has been written to this standard, it can be reused in many other products. Linux, even at the kernel level, provides a POSIX interface for the basic functions. This is further enhanced by a runtime library which is linked with your software.
Linux and POSIX
Because of Linux and POSIX, not all of your code has to be changed if you change the hardware. Let me give you an example. Suppose you were making a weigh-scale. It is a box that is connected to a strain-gage. It has some calibration, tare, linearization, and temperature-compensation routines. It is nearly identical to last year’s model but you couldn’t get the processor anymore and, since it was a new product, you decided to change the display.
Just some drivers
If you had used Linux and the POSIX interface with the old product, you’d need to write a new display driver, and new hardware interface to the strain-gage. That’s it. Perhaps there might be a few code changes to take advantage of the new display, but otherwise major portions of last year’s code could be reused.
This might not work
If the code for the last product isn’t available anymore, isn’t documented, or was poorly written, you can’t reuse it. That’s where Route 495 Software can be helpful. We know how to write reusable code. We also know how to document it so it will not only pass your QC department’s inspection, but also use the methods, words, and interfaces about which the software community has been trained. This makes it appealing to the software engineer who is expected to reuse significant portions of it.
Home page
This webpage copyright © 2009, Route 495 Software, LLC