Functional Prototyping Series: Transitioning from Paper to Software Design

The Functional Prototyping Series is a collection of articles that walk you through the prototyping process. Read on for key concepts, benefits of prototyping, product choice discussion, and additional technical resources.

The Importance of Paper Design

New ideas are exciting. But where do you go once you think of an innovative idea? What is the first step in creating a functional prototype to ensure product success in today’s competitive market?

This tutorial outlines the first steps in creating a successful prototype – a paper design to help you transition to a software design with minimal difficulty.

With an exciting and innovative idea for a new device, you may be tempted to skip paper design altogether and just start on a physical prototype right away. Resisting this temptation will save you time and wasted effort in the long run. The time you invest in paper design pays big dividends later and helps you avoid many common pitfalls in the design process. Paper design does not mean writing out your detailed design for your prototype on paper with a pen or pencil. Paper design is creating a plan before doing any software coding or hardware design.  Some of the benefits of paper design are discusses below.

Getting Ideas Out of Your Head and on Paper

Solidify the details surrounding that great idea you have been kicking around. The more detail you can put on paper, the easier it is to translate to an actual functional prototype.

Fail Now, Not Later

Explore all the possible permutations of your idea. This is the time to let your imagination run wild because the biggest expense at this stage is time. Find the best implementation now while there is no sunk cost associated with a failed design. Fail early, fail often, and fail forward in the paper design phase to ensure your design is up to snuff.

Get Peer and Customer Feedback

Build consensus with partners and peers and obtain buy-in from early customers and investors. A good paper design helps others fully grasp your idea. The more effective you are at explaining your design ideas, the higher the quality of your peer feedback and the more likely you are to get funding and support. Even this early, you should be iterating on your design until it is defensible and stands up to critique.

Leverage CAD Software for Visualization

Use available computing resources to make a professional, detailed physical design. A design defined in CAD software with dimensions, notes, and materials specified is much more powerful than a back-of-the-napkin sketch. It implies a detailed, well-thought-out design and a serious intent. This helps you gain consensus and get buy in because others can more effectively visualize your design.  This is strictly for visualization purposes.  Resist the temptation to move forward with the detailed design of your functional prototype at this stage.  A more detailed design will come later.

Use a Graphical Representation of Your System

Use standard techniques like a flowchart or a state diagram to define the functionality of your device. This flowchart or state diagram forms the basis you need to make software architecture decisions and defines the framework of your algorithm design.

Define Your Requirements

How do you go from a great idea and a back-of-the-napkin sketch to a detailed paper design? The first step is to clearly define your goals by making a list of user requirements. These requirements should be as specific as possible. Research is crucial at this early stage to be sure you can meet your outlined requirements. Is your design feasible? Will it realistically be able to meet your requirements? Make sure that you distinguish between needs and wants for your design. As an innovator, you may be tempted to add advanced but not completely necessary features to your prototype. Know your objectives and stick to them.

Abstract Components from Requirements

With abstraction, you can describe an application without defining how to write the application. Abstraction generalizes the application to a high conceptual level. There are generally two types of abstraction, procedural and data. Procedural abstraction separates what a procedure accomplishes from how the procedure is implemented. An example of a procedural abstraction is opening a file. You can go about opening a file in many different ways, but you do not need to be concerned with that when abstracting.

Data abstraction separates the data you want to store from the physical means of storing the data. An example of data abstraction is an array of data. An array can represent data with a more logical view without requiring the user to be concerned with the details of its implementation. To assist with abstraction, remove key verbs and nouns from your system requirements document. From these verbs and nouns, you can determine what your program needs to accomplish and the objects that will be a part of your user interface. The verbs and nouns also help you determine the hardware components necessary to complete your prototype. 

Flowcharts

Once you have a set of abstracted components you have gleaned from your device requirements, you can use a flowchart to move from abstracted components to a software program. Flowcharts help you develop a good understanding of the application flow by dividing the application into more manageable pieces called nodes as shown in Figure 1. NI LabVIEW is a graphical programming language designed for measurement and automation applications, which makes it an ideal tool for quickly converting your paper design to code. Since a LabVIEW block diagram is similar to a flowchart, moving from the flowchart to software code is a quick process.

State Architecture

State Diagrams

A state diagram is a specific type of flowchart that indicates the states of a program and the transitions between states. Each state satisfies a condition, performs an action, or waits for an event. The transitions between the states are conditions, actions, or events that cause the program to move to the next state. State diagrams are useful for prototyping because almost all embedded systems use state architecture. That is, they are designed with the understanding that the prototype is always in a given state, even if that state is idle.

To begin creating a state diagram, you need to have a full understanding of your application and anything within your system that is part of your user interface. This can be a value that is displayed or a user input such as a numeric or Boolean control. A well-designed flowchart assists in this process. Next, write down each state and how your prototype transitions from one state to another.

State Machine Architecture

State machines are useful for reactive systems. That is, their behavior is dictated by logic based on user inputs, acquired signals, and system changes. When you implement a state machine, you define the transitory nature of your system based on this logic.

In LabVIEW, a state machine consists of a case structure, while loop, and shift register. An initial case is specified outside of the loop. Each state from your state diagram corresponds to one case in the case structure. Each case contains code that implements one state and logic that defines the transition to other cases. This architecture gives you the ability to scale your application by adding more cases and logic to the state machine.

Figure 1. The flowchart, state diagram, and state machine for a blood pressure monitor. Note that the five states defined in the state diagram are implemented in the state machine.

LabVIEW Statechart Module

The LabVIEW Statechart Module provides an even more direct route from paper design to software design. With the LabVIEW Statechart Module, you can design software components in a state diagram and define the behavior of the states and transition logic. The statechart is fully integrated with LabVIEW, so all the same graphical programming concepts and dataflow programming practices still apply. You can design each state with multiple reactions that correspond to a variety of triggers, or events, that are sent to the statechart from a hardware device or user interface. The reactions are implemented with LabVIEW graphical programming. The LabVIEW Statechart Module is perfectly suited for prototyping applications for users who are programmers by trade.

Figure 2. The LabVIEW Statechart Module implements the states of the blood pressure monitor.

Next Steps

Prototyping plays a key role in designing and deploying innovative ideas to market. The first step in creating a successful prototype is to design on paper in such a way that enables your software transition to be as seamless as possible.

By fully defining the requirements of your design, abstracting components, and creating flowcharts or state transition diagrams, you can ensure a firm foundation on which to build your prototype. With the LabVIEW Statechart Module, you achieve the rapid development needed to prototype as well as tight hardware integration with the LabVIEW platform. 

To learn more about the technical aspects of transitioning from a paper design to a software design, see the related resources below. To continue on to the next steps in the prototyping process, return to the Functional Prototyping Series.

Related Resources

Developing Applications with the LabVIEW Statechart Module

Software Solutions for Embedded Development

More Information on Prototyping

 

Reader Comments | Submit a comment »