Prototypes and Breadboards are part of Non-Recurring Costs of any engineering development. Market Penetration units and Pilot units may be allocated to sales or operations, but are similar in nature, and are also discussed below. What is common is that none of these support articles are "sold", they are all expendable material used to support development and test.
There is no common naming convention for these units, and one item may be used to cover several purposes above, making understanding of the purpose of these units more difficult. There may be a tendency to hand wave through this part (I need 10 units - how I use them is my business!). In the real world, the actual purpose of each of the units, and its required maturity to accomplish its purpose, must be kept in mind when planning the job.
It is clear the number and timing of these assemblies is very critical to success. The delivery and functionality of these units provides verifiable measure of the actual state of the job. It is where the rubber meets the road.
The purpose of a breadboard is engineering risk reduction. They are units that contain limited elements of the final product, but have a feature or path of the final system completely implemented or modeled. The result may not physically resemble the final system at all - unless it is a mechanical breadboard, which is generally referred to as a mockup. The hardware, and sometimes the software, is usually constructed by engineering technicians or model shops, and documentation is solely up to the engineer. An embedded product development system running on a desktop computer is in effect a breadboard of the final system.
Their purpose of a breadboard is to enable the integration and test of Specific Elements of the design. Thus, the rest of the system is simulated, by software, electronics, mechanical switches or other means. This also allows for interface conditions to be varied in a controlled way to test the limits of a function - one of the real powers of a breadboard. A single product may have several breadboards of different types to enable verification of design concepts or integrate code or components.
Breadboards are used for Engineering Testing or feedback, to verify that the assumptions, calculations and assertions made by the engineers and the vendors of parts and processes are true. They are rarely part of formal testing or acceptance.
Examples of breadboards I have known:
Electrical Design: For power system design, I would typically design an "inside out" fixture, to allow the components to be accessible. Most compact final designs are practically unprobable. These breadboards included specific test hookups that were not in the final product, like impedance matched connectors to examine high frequency waveforms. Engineering test went much faster than trying to test with everything all balled up for production.
Mechanical Design: A mechanical breadboard may be produced to support fit checks, packaging development, or mechanical tests at the next level of integration. A mass model is a breadboard, and is used to support vibration and shock testing of the equipment that is to hold it. it has the tie points, fasteners, and weight distribution necessary to support testing of the support system. May also include heaters to support thermal testing.
EMI: To verify some very stringent EMI requirements, we built EMI breadboards, consisting of the entire mechanical assembly and filters. We placed a clock circuit run by a battery to simulate the electronics. This allowed us to determine the effectiveness of our shielding approach, and we made many changes based on it.
Embedded Software Development: To integrate VxWorks drivers, we bought commercial assemblies which used the parts we were planning to use in the custom design. We then hacked them up to make a unit that had everything hooked up the way we were going to use them. Looked ugly, but worked, and gave the software people a 2 month start ahead of the production hardware to check out driver capabilities.
Emulation Systems: No longer needed, due to the integration level of modern processors. Thank God!
Power Design: A lot of power and battery characteristics are hard to quantify or control during testing, so we typically built breadboards to test the interaction of power components. That way you can modify their characteristics with external components to verify that they do not interact badly. Simulation can do some of this - as long as you have a decent model, which you frequently don't.
Software: We have breadboarded software development processes, taking them all the way through the process to verify the procedures and support components really integrate, before we have huge images and deadlines.
Breadboards are usually set aside after the real units become available. As updates go into the real units, the breadboard is quickly made obsolete. The trick here is to make the breadboard reliable, and usable for its specific purpose, but not to spend tons of money on something that should have a very short life span. The question to ask: What risks am I addressing with this breadboard? When will I know the answer? Will it tell me anything I can act on in time to affect the design? After that, it goes to the bone pile, perhaps to be recycled someday.
I have seen many breadboarding efforts get behind schedule, then get set aside before completion as the real hardware and software show up. Which makes the breadboard effort a total waste of effort.
So the real decision point of a breadboard is whether the cost of it (which can be considerable), is worth the risk reduction. Many times the cost of this hardware and software is missing from the estimates. Sometimes this is because you have bone pile or scrap hardware laying around is used, but most of the time, there is a considerable expense building these units. Make sure that they complete in time to be tested, and useful.
If you have few risks, you can avoid breadboards all together. But on any new concept, you probably will be better off with breadboards for a few items.
Important: Record the actual test configuration. This is completely the responsibility of the engineer. If you have not recorded what you have been testing, how do you know what worked?
Prototypes are units built to production drawings, but without using high volume production methods. They may be built by a special operations crew, lab technicians, and engineering is heavily involved. They may be built with shortages, missing functionality, or extra components installed to support the next phase of integration and test. There is design control (drawings are typically released), but drawings are marked up during or immediately after construction.
Uses for prototypes are:
First article inspection
Marketing exposure and feedback
Software integration
Formal Qualification Testing
Engineering Test
Production Test Development
Operations Methods Development
System Testing
Design for Manufacturing (DFM)
Verification/Validation
System testing can be a major load. For example, a system we did for monitoring electric meters required a full neighborhood of prototypes, numbering into the hundreds, running simultaneously, plus all the support hardware and some simulation software to perform a system test. These were all "prototypes" in that the production run was much less than the 1000s per month that were going to be produced.
Prototypes typically do not include product shipment methods, final labeling, enclosed documentation, failure analyses or quality reporting, or accessory kits. These operations may also be prototyped, but on a parallel path, to be brought together during the Pilot run.
It is best that they are built by the eventual operations facility. This way, production methods are prototyped along with the design, and direct trade offs can be made. But high volume facilities do prototypes very poorly and are reluctant to participate for this reason. Don't be surprised that the production facility does not perform very well doing your prototypes for you.
Building at a facility experienced with prototypes is cheaper and provides units more quickly, but masks problems with the documents or components that the prototype house simply works through. Prototype facilities are used to working with incomplete/changing documentation. If you use a separate house for prototypes, you are in effect starting up two very different manufacturing lines, with differing capabilities, and will incur this cost twice. Pay me now, or pay me later. Depends on how badly you need to meet your schedule, and whether you can afford integration with two facilities. Another benefit to integration with two facilities is you have some backup should one of them develop problems. See Resource Constraints.
A fairly new method of building prototypes is a single zone oven - something like a toaster oven on steroids. Ovens like this can solder a board at time, which for some prototyping, provides adequate quantities - five a week easily. And a lot of prototype houses do not have sophisticated 12 or 14 zone convection ovens needed for the modern high density BGAs. Complex profiles would be no problem for a single oven doing a single board. And atmosphere control is possible, too. So for complex prototypes, it really makes sense.
Enclosures and mechanical parts can be prototyped using SLA methods, soft molds, etc. Be sure that the method for the mechanical prototype supports the environments you will be encountering (Will the finish be acceptable to Sales? Is the material strong enough for drop testing? Can it be painted and handled?).
Lots of prototypes do not guarantee that the engineering will be finished sooner, in fact, I have seen too many prototypes take a program down. One engineer had five failed boards with the same part blown, but was "too busy" to find out why the part had failed several times - he just got another unit and continued. A serious design issue was waiting to be discovered.
An engineer needs one working unit (and they can share it with others), a system test needs a quorum, and there need to be spares in case of accidents. It is better if prototypes are shared - it tends to make engineers clean up after themselves, and helps enforce discipline. Giving everyone their own prototypes and development environment has always led to problems during integration. The individual "copies" tend to diverge, which must be reconciled before a single design can be settled on. Providing personal units to each individual actually makes the overall effort take longer. Happened every time I saw it. If everyone keeps using their own sandbox, you will never get finished. Get to everyone using standard units or build as quickly as possible.
Test equipment can also be very useful during engineering testing. Buy and build it early. By the time engineering testing is over, this equipment can go out to the floor for production test.
Here is an article on calculating the number of prototypes you need: How Many Prototypes Do We Need?
Tracking where the prototypes are and what their state is can occupy a lot of time. I recommend this:
Prototypes have three classes of users:
Class 1: The design Team
Class 2: Other engineers, performing validation, test or integration, a little larger group
Class 3: All other Users, a very much larger group
Class 1: The early units that go to engineering - elect, mech, software - don't try to track those with anything. They will be pulled apart, modified, experimented on, instrumented. Tell the engineers to keep them up to date. Be reluctant to give them many, more units increases maintenance costs, and usually leads to inconsistent test results and backtracking because the units are difficult to keep identical. It doesn't matter that they only cost $50 each, it is the fog factor of having lots of units laying around in uncontrolled states that causes trouble.
Unit A failed, so I got Unit B and put the X from Unit C on it , but the X didn't have the change that was in unit A, so I pulled it out and it worked again. I think it is ok. The purpose of an engineering test is to find and fix design problems, not just to get some random combination of components to pass. In this case, the engineer should find the problem in the unit under test. Even if a second unit passes, you still have to find out why the first one didn't. The problem is in there. It may be an uncontrolled aspect of the setup, software, or construction. It happened, it will happen again, and can be something other than the unit under test. If something is going into production, there can be no mysteries.
Class 2: These should be under configuration control of some sort, although the labeling and other parts may not be complete. Engineering can use these for final testing, but they should not be modified without configuration management. Most configuration and support management software has a way to track these early units, although operations may not want to - it will be time intensive. If you cannot use your high power configuration tool, use your own software tool to keep track of serial numbers and configuration status. This is difficult. I have tried it on line, but you discover the reason for that stupid formal sign off process. People in general will not keep track of updates unless the program stops until they enter the data.
Class 3: Should be under full configuration control, including support. This part of the product needs to get worked out sometime, may as well start.
If major feedback and update is encountered during the prototype phase, a second batch of prototypes may be necessary to perform regression testing. Since prototypes are usually 2x to 5x the cost of the production units, this can be quite an expense. Some of the units can be dual purposed, although this becomes difficult in a tight schedule. You will also lose units to accidents and wear. And you may want to keep the environmental units as is for a time, in case there is something to investigate when the units hit the field. This is especially true for power and thermal issues.
Production pilot units are to wring out the actual production process. They are built to the final drawings, by the high volume manufacturer.
I don't know how many times people ask me if the Pilot units can be built at the prototype vendor. This defeats the purpose of the pilot program!
There is some reasonable number of units built, usually selected by the production house and/or Quality. They are then tested and inspected to make sure that the drawing package is complete, and the line understands and can execute the production run. This run is used to determine the final costs, and also to demonstrate any in process quality actions that must occur before introduction. It includes testing, the shipping concepts, enclosed paper and manuals, quality feedback processes including electronic transfers and failure analysis, the works. There may be a few Engineering Changes, but this should be mostly a production methods test.
Pilot units can be used as prototypes or Market Penetration Units, but you will probably find that the timing does not support a reasonable schedule. It is better to stay focused on using the pilot run to support operations development.
The purpose of a market penetration unit is to allow the customer to use the unit, in their own environment, to determine if the package and function suits their needs. They enable study of use cases and system development can proceed with the Market Penetration Units as examples.
Market penetration units may be prototypes, or breadboards, or pilots, or have their own construction unrelated to the eventual product. The insides of the unit need not be the production hardware or software. It may be assembled with off the shelf components, or not meet the production cost target, or will be replaced with a smaller footprint, or be implemented with a display that will not be used on the final unit.
The purpose of these units is to establish value with the customer, and use the customer feedback to design a more tightly specified product based on better knowledge of what is and is not important to the customer. For instance, you may be working on a design for a unit to be dropped from the passenger window of a heavy truck, only to find out that the unit is rarely removed in normal service. Or discover that the unit cannot be mounted easily or used properly in the locations planned, and requires a different user interface.
The cost of these is not critical, there should not be many of them. These units need to be rock solid in reliability, have predictable performance, and have a good appearance, even if they are little limited in functionality. It is much easier to convince a customer that a reliable, durable unit can be made more capable, than to convince them that a fully featured, unreliable unit can be made usable.
Asset allocation can be complex, here is a method to make this more straightforward.