3D printers are cool!  I watched a TED talk this past year about them.  I know they have been around for over 30 years, but I still think they’re cool.  As I watched, I thought of the wheel for my dishwasher’s roll-out rack, which had recently fallen off and melted on the heating element.  In theory, if I had a personal 3D printer, and the printable data were available on the internet, I could print a replacement wheel within minutes of discovering the broken part.

I then started to think about what it takes to make that actually work.  The data describing the wheel has to be available.  The data has to be sent to the printer through a communication protocol understood by both the sender and the printer.  Additionally, the data has to comply with a format the printer can render, or I might end up with a wheel that was less functional than the one I melted!  Once received by the printer, the data has to be passed from software module to software module to set up, and execute, the rendering process by controlling the hardware.  In other words, to replace my broken wheel, the specification for the wheel needs to be converted into different kinds of data, in different kinds of data structures, which comply with the external and internal interfaces provided by the 3D printer implementation.  Designing the software for a product like this one seems daunting, until the principle of modular design is considered.  By partitioning the software for the product into smaller, functional modules, the task becomes easier to implement… and easier to test.

3D printers are cool, but so are module tests!  They too have been around for over 30 years, but are still cool.  Aside from careful design and implementation, module tests and code reviews have long been used to ensure that a released module performs correctly in every scenario for which it is designed.  In fact, IEC 61508 requires modular software design.  Module testing is a workhorse of software quality control.

What is a module? 

A software module, according to the IEC 61508, is a “construct that consists of procedures and/or data declarations and that can also interact with other such constructs.”  Interaction between modules is accomplished through an interface as “understood” by both the module itself and a consuming module.  Keep in mind that a module does not include any hardware with which it interfaces.  The purpose of module testing is to test the logic of the software module only.  Software integration tests software module interactions, and software/hardware integration tests interactions of software modules and target hardware.  So, even a module test designed to test a C function, whose sole purpose is to read a hardware value and convert the data to a digital format, is not required to run on target hardware in order to verify the function’s operation.

There are several different software constructs that could be considered to meet this definition:  a library of functions, a C-language source and header file which encapsulates a certain software function, a C++ class, a COM object, and so on.  Which of these possibilities is the right choice?  Any of these choices works, in the right context.  One of the philosophies of the IEC 61508 standard is to define requirements for safety without prescribing how to implement those requirements.  So, as long as a “software module” is defined, in project-specific terms, and that definition does not violate the IEC 61508 definition, you’re in business.

Next week in Part 2 of this blog, we’ll cover module interfaces, module testing goals, code coverage requirements and module test plans.  To be continued…