Who Does The Design?At a recent manufacturer's event, I had an enlightening conversation with a fellow consultant and a manufacturer about programming issues and software or design support. 10/17/2007 6:57 AM Eastern
Who Does The Design?
At a recent manufacturer's event, I had an enlightening conversation with a fellow consultant and a manufacturer about programming issues and software or design support.
For a number of reasons, my consultant compatriot tends to let the contractor work out the signal flow and the interface of the DSP, although it depends on the complexity of the system and the skill set of the contracting pool. In many instances, this consultant is confident of the contractors' abilities. His reasons for taking this approach? First, as the number of DSP systems has proliferated, so have the paradigms for how that system should operate, what kinds of signal processing blocks are provided, and how the user interface should be designed. Multiplied across half a dozen or more hardware/software packages, that is a lot to learn and keep current with. It requires time, and you know the rest of that equation. Second, he feels that contractors, who are also doing a lot of their own design-build projects, tend to be most familiar with all of the vagaries of a particular DSP system and how to optimize the system for the application. He also wants to be sure that the contractor will support the installation and any changes the client might need or ask for after the project is completed. And finally, this is one way he can help educate contractors or encourage them to be educated about the systems they use and how to use them. He will review the contractor's work, when necessary, to make sure it reflects his design intent.
I know a contractor who holds very similar views to that of my consultant colleague. In fact, he prefers to do the DSP programming, as he feels he has to start over from scratch with any design he receives from a consultant anyway.
The manufacturer in this conversation feels that it is not the job of a manufacturer to do this design work. He feels very strongly that to do so will detract from the livelihood of the consultant or the contractor. A manufacturer provides the tool, and a consultant or contractor learns how that tool can be used and designs accordingly. Part of the toolkit includes education on the hardware, software, and control of their systems, including examples of how a variety of projects might be approached using their gear.
I know that his view is not universally held in the manufacturing community — it isn't even prevalent across his company. Other manufacturers have taken the stance that they are the only qualified designers of systems containing their equipment.
I feel strongly that it is vital for the consultant to provide the DSP signal flow programming. While my system block diagrams have more “white space” and look much simpler than they did prior to the digital era, they are no less complex. It's just that one box, or set of boxes, has absorbed most of the mixing, processing, and distribution equipment that used to populate multiple pages. I don't believe that much of that design work can be described easily in words as part of the specifications. A picture is worth a thousand words, which is why our specifications are a lot thinner than they could be. It still requires the knowledge of what the client wants the system to accomplish and how the equipment will achieve those goals. During the design stages of a project, the consultant has the responsibility of translating those goals into working systems.
One of the major issues has to do with publicly bid projects. There are often requirements that more than one manufacturer for each type of device is listed in the specifications. This can be circumvented by showing that the owner has a vested interest in limiting the number of manufacturers to a specific manufacturer if the costs of ownership and maintenance can be reduced due to standardization by the owner. Another avenue is to prove that multiple responsible bidders have access to a specific manufacturer or device. This can, of course, make the design process much easier as you are concerned with designing for only a single DSP manufacturer.
Why is this an issue? Not all DSP units are created equal. Input and output structures vary considerably, as do control capabilities, and user interfaces. Designing for multiple DSP devices drastically increases the amount of time spent on design. You don't have the luxury of creating a single design.
One solution is to create a performance specification instead of a full specification, leaving equipment selection and programming up to the contractor. Another is to wait on DSP design until after the successful contractor has been chosen and they submit on the equipment they plan to use for the project.
How do we create a cohesive whole out of these various patches?
The solution lies in our ability to work together as a team and the part we play at each stage of the project. First, some ground work should be laid. Manufacturers should continue to provide training opportunities for consultants and contractors. But factory training should be only one aspect of a multi-pronged approach to training. One major concern of consultants relative to training is the loss of billable time for their staff if they have to travel to the factory. I am pleased to see that one major audio manufacturer is offering Web-based training for their DSP systems. InfoComm International's Web-based training is about to expand beyond the basic courses and into the higher level offerings. It's time to use the available technologies to train those who will be using the software. If more in-depth training is required, consider offering classes during the major trade shows.
Manufacturer support continues during design, as the consultant determines client needs and the most appropriate technology available. A technically knowledgeable consultant liaison is an invaluable asset to the consultant and to the manufacturer. Once the basic design is in place, the manufacturer should be involved in reviewing the design to ensure their hardware and software will perform as intended. It is always valuable when the manufacturer is able to tell me honestly if their product won't fit the application, they don't have a particular module available at the time, or that my design will not work as intended as shown in the documents.
The contractor is typically the last member added to the team, as implementation of the design moves forward. Part of their role, beyond implementation, is to keep the consultant apprised of changes that could affect the design or that could improve the design. This again involves the manufacturer and also requires clear communications and good relations between all parties. There are always aspects of a design that I can find to improve. Sometimes I find them myself, and other times, they are pointed out by the contractor. Going into a design, I know that there may be more than one way to approach the project, and more than one solution to a particular problem. A good contractor brings a wealth of knowledge to the table and the ability to be able to communicate that knowledge effectively.
Effective design and implementation requires the active involvement of all parts of the team; we each bring a unique perspective and a “library” of solutions that helps move the project forward. As we work together as a team, we'll all walk away knowing how we can improve next time.
Thom Mullins is a senior consultant, specializing in systems design, with BRC Acoustics & Technology Consulting. His e-mail address is firstname.lastname@example.org.