Microprocessors are ubiquitous. Today’s toothbrushes and razors come with microprocessors built in. See for example, Schick’s Hydro Razor  and “Inside the Schick Hydro Microcontroller Powered Wet Razor“. This popularity has been fueled by the perception that “intelligent” products are better and enabled by rapidly declining costs for microprocessors.

A microprocessor is a general-purpose computer contained on a single integrated circuit. It has flexible functionality largely defined by software, which essentially is instructions directing logic circuits to perform calculations and to read/write voltages on pins. Microcontrollers (the Swiss army knife of microprocessors) may include many functions on one IC – features like communication ports, motor controllers, timers and comparators. This integration of functions may make a microcontroller a less expensive and more versatile solution than one using discrete electronic parts.

Often products include a microprocessor because the design can then adapt to evolving requirements without revising the hardware. Simply changing the software can change how the circuit functions. The designer gains the flexibility to add new features, even after the product is in the field.  Hardware development can proceed before all the requirements are nailed down. However, one should not allow the convenience of rapid changes to circumvent proper verification and validation of the changes’ effects on the whole system. As the blog “What’s Your Problem?” (Jan 2012) points out: a quick way to send a project sideways is to throw a cutting-edge technology at a challenge without a deeper look at the underlying design goals. A well-executed design process encourages understanding the requirements and risks presented by the medical device as a whole, before deciding on the software/hardware split.

If we look at the razor application as an example, the core functionality provided by the hardware/software system seems to be:

• User input to select between one of three vibration speeds
• Motor control to provide the selected vibration
• Status indicator
• Battery monitoring

These functions can be implemented using logic circuits, without software, about as easily as a microcontroller-based solution. How to choose? Factors one might want to consider include: availability of hardware and software engineering resources; familiarity with the design tools; marketing requisites; power consumption and parts costs; longevity of the product design; intellectual property; ease of testing; and project schedule.

Before committing to a design that includes a microprocessor and software, it is prudent to be aware of the regulatory consequences to the development process. In medical device development there was historically less focus on software’s contributions to a product’s reliability and safety as compared to hardware.  IEC 60601-1-4 (now clause 14 of 60601-1:2005) has for a long time set out requirements for the process by which Programmable Electrical Medical Systems (PEMS) are developed, but it primarily addressed the integrated hardware and software system. More recently IEC 62304 has defined and expanded upon the processes, activities, and tasks – the software development lifecycle – required for medical device software. There is considerable overlap; see Annex C in IEC 62304:2006 for a detailed comparison to the requirements of other standards. If one can simplify the regulatory burden on a project by omitting software, or ensuring that it is used only for functions having a lower risk classification, then there may be positive benefits to the project schedule and budget.

There are of course times when software is the right tool for the task. A medical product requiring  extensive user interaction, or one that performs and displays results from lengthy calculations, or has complicated data to be acquired and stored, is a great candidate for using software to solve the design challenge.  Designers should avoid committing to the decision of including a microcontroller until after the design requirements are clear and the risk assessment process followed. This approach increases confidence that functionality is appropriately apportioned between software and hardware.

Once you understand the question well, you will know whether software is the right answer.