DESIGN CONTROLS

Medical Device & Diagnostic Industry Magazine
MDDI Article Index

An MD&DI June 1997 Column

FIRST PERSON

The managing director of LaBudde Systems, Inc. (Westlake Village, CA), outlines a regulatory strategy for improving design.

Contrary to popular belief, the design control requirements that are outlined both in ISO 9000 standards and in FDA's new quality system regulation are not only necessary, but should be toughened. As currently practiced, engineering lacks rigorous methods for capturing design requirements and verifying and validating the design itself. Mandating such methods through regulation is the only way to ensure the uniform development of quality products.

FAILURE OF LOGISTICS

ISO 9000 standards, total quality management, and the FDA quality system regulation require that manufacturers include logistics items in their development and manufacturing protocols. These include packaging, labeling, handling, shipping, installation, training, maintenance, and repair considerations. Engineers should also address these issues.

But solving logistics problems isn't enough. Poor product quality often results from bad design. Using design controls is necessary to ensure better products. But the ISO 9000 design controls, now part of FDA's device quality system regulation, do not go far enough. They require only that development include planning, requirements (design input), designs (design output), and document controls. Unfortunately, the controls do not define how to implement these requirements, so there is a substantial risk of design problems. Simply documenting a risk-prone process will not correct design deficiency.

FAILURE OF REQUIREMENTS

Our engineering discipline lacks sufficient methods for design requirements capture and validation. Most companies fail to capture all product requirements; most of their product specifications are incomplete, ambiguous, and inaccurate. In a large number of companies, marketing and engineering departments have trouble communicating with each other, thereby stifling requirements generation.

More often than not, users are left out, seldom getting the chance to validate requirements. Most requirements are documented by the use of natural language (text) documents that cannot define complex function, behavior, and performance requirements unambiguously. Each technical discipline uses different methods of requirements generation, leaving substantial communication gaps between the various technologies used to create the product. Designs cannot be properly verified if the requirements are inadequate. This often leads to inadequate product design. The result is that function, behavior, or performance fail to meet customer needs.

Most companies don't emphasize requirements or understand how they relate to design. There are usually poorly defined interfaces between requirements capture and design and documentation.

FAILURE OF PRODUCT DESIGN AND VERIFICATION

Design verification also needs improvement. Medical devices often consist of components using chemical, mechanical, electronic, and software technologies. Engineers must consider each technology when verifying product performance. But the current tools they use are inadequate.

There are several tools available for each of the technologies used in product design. Mechanical and electrical engineers have reasonably good computer-automated design-capture and design-simulation tools. However, these tools are mostly bottom-up (i.e., they require a detailed design) and have no place to embed top-level requirements into the design elements.

Electronic design products are among the most advanced design technologies. Yet, most schematic-capture products have no way to embed design requirements into the schematics. One notable exception is IntuSoft's Design Validator Spice tool, which allows requirements definition and simulates performance. Performance requirements are usually left to manual linking and verification, which are error prone.

Of all engineers, software engineers enjoy the fewest benefits from computer automation. There are signs, however, that some engineering and Windows-based products are being better supported with integrated development environments that allow high-level design entry and automatic code generation. But simulation is still missing from those products.

There are very few cross-disciplinary tools that capture and evaluate designs based on several technologies. A tool developed for electrical design cannot be used for mechanical or software design. These tools do not support a high-level abstraction of product function, behavior, or performance, but rather require a physical design. So engineers must currently manage interdisciplinary products by using cross-function teams rather than high-level design tools. The result is that total system behavior is often not understood.

Many companies manufacture products after testing only a limited number of units. Our research shows that engineers use few statistical sampling techniques, resulting in inadequate design verification. A sample of one is only valid for verifying math models. Also, engineers often specify acceptance test tolerances that do not consider product degradation due to environmental and life cycle factors. The result is poor product performance in the customer's environment.

LIMITATIONS OF CURRENT MANAGEMENT SYSTEMS

Nearly all existing project management planning and scheduling tools are based on task planning and the waterfall life cycle planning model. Unfortunately, users often end up spending a lot of time and money updating these tools during development. A project with more than a half-dozen engineers requires a full-time operator just to keep up with changes. And on large projects, the tool rapidly gets out of synch with the real project, and the level of detail that can be tracked is limited.

Existing planning systems can't link plans to item-tracking databases, requiring managers to build their own system and manually link each item. In addition, none of the existing planning systems can be linked to requirements-capture tools, design tools, or production systems like management resource planning systems. As a result, these planning tools require managers to manually connect management tools to engineering.

TOOLS NEEDED FOR THE FUTURE

Requirements-Capture Tools. A requirements-capture tool is a device (usually a computer program and database) that allows users to define what a product must do (i.e., functional design). It defines top-level (user-oriented) requirements and translates them into lower-level (designer- or manufacturer-defined) requirements with complete traceability. The tool helps prioritize requirements and automatically generates specifications for various sections of the product.

In the future, marketing and engineering staff will analyze user involvement with products. We will collect all product requirements and interfaces into a top-down system-requirements-capture tool that is independent of implementation technology (we will not be concerned with how the product will be made at this level). We will be able to simulate product functions, behavior, and performance before design details are determined. Thus, our requirements-capture tool will need to allow us to link requirements to equations that can produce actual numerical values through the use of simulation or analysis tools. Most of the equations will be contained in drag-and-drop prebuilt libraries of standard functional parts. Users will be able to simulate interactions with product interfaces by using virtual reality to validate product function, behavior, and performance--all before we even know how the product will be made!

The requirements-capture tool will need to have placeholders for all requirements including function, behavior, performance, environments, safety, logistics, manufacturing, and disposal. It will need to automatically trace and validate requirements. This tool should make complex system designs easy to understand by using graphics rather than the descriptive language of requirements-capture. It should allow project managers to generate reports on the status of all requirements and identify those that are missing or conflicting. We will automatically generate compliance or trace matrices for tracking the assigning out and validation of requirements.

Some companies are already offering parts of these system tools. Ascent Logic's RDD-100, Mesa Systems' Cradle, and i-Logix's Statemate are good examples. These are expensive, complex system- level tools that integrate requirements capture, function, and behavior simulations (and some automatic code generation). Because they require a lot of instruction, the cost and time required to use the tools may be too much for a small company. And they are incomplete because they do not have placeholders for all requirements and do not simulate all functions, types of behavior, or especially performance requirements.

There are some tools, such as Vitech's Core and Requisite, Inc.'s, RequisitePro, that use natural language for requirements capture. They have many of the needed features but have difficulty with graphical representations.

Until low-cost system-level requirements tools are available, we need to devise them ourselves. We can generate, capture, and validate requirements effectively by using a combination of organizational management and manual and semiautomatic techniques.

Organizational management involves manually ensuring that requirements are reviewed by, approved by, and disseminated to the proper organizations by physically moving documents around within the organization. This requires review and follow-up to ensure that requirements and design are properly related.

Current off-the-shelf office automation products enable users to build tools that integrate and link documents, drawings, specifications, and reports. Drawing tools produce graphics of product function, behavior, and performance, and captures them with traceability. One example of a semiautomatic tool (one that requires some manual links) is Shapeware's Visio, which attaches performance requirements to graphical objects in drawings and links objects to databases. It has an interface to AutoCad and stencils for nearly every technical discipline. A company can build its own system requirements and design-capture tool by using many of these off-the-shelf products, as long as it has a good vision of requirements capture, understands how to handle cross-discipline interfaces, and has organizational management skills.

Design Tools. A design tool is a device (usually a computer software package) that allows users to define how a product is made (i.e., its physical design). In the future, we will need design tools for systems composed of all the technologies used to design products. They will need to include or interface with mechanical, electrical, software, optical, chemical, and biological design tools. They will need to be tightly coupled to requirements-capture tools by assigning requirements to physical design, and they will need to be able to translate high-level abstractions of product design into physical design. High-level abstractions of function, behavior, and performance will allow users to easily design complex systems by using hierarchical abstractions. Engineers will verify the requirements and designs by using automatic test tools, such as analysis and simulations, even before the product's physical design is selected. The tool should automatically check design against requirements for completeness and consistency. It should allow proven designs to be reused. Any changes to the reusable part should be noted so they are properly verified.

Design engineers will be working more with high-level designs rather than low-level coding or circuit designs. Devices will be automatically created from high-level abstractions that will output mechanical, chemical, electrical, and software designs that are defect-free. For example, a phased locked loop will automatically be designed from bandwidth and stability specifications by design tools. The tool will automatically generate VHDL specifications for hardware and computer code for software.

There are some tools available that give us an idea of what the future holds. MatLab's Simulink and Integrated System's Matrixx capture and test system designs and output computer code for the software portion of design. But they still can't link designs to requirements. Presently, there are no technology-independent, high-level system design tools that cover all design technologies, but engineers can use many of these existing products as a bridge between high-level abstractions and physical design.

Project Management Tools. Future project management systems will need to allow users to track deliverable items rather than tasks and support other developments like the spiral model. They should be tightly coupled to requirements capture and design tools. When a requirement or design is created, a placeholder should be noted in the management tool so that resources and schedules for the items can be planned and updated. Changes in requirements, design, or planning should be simultaneously and automatically updated everywhere at the same time.

Additionally, the engineering tool set should be tightly coupled to the manufacturing systems like MRP, so that everyone in the company can determine development status.

CHANGES TO REGULATORY REQUIREMENTS

To correct the deficiencies in how engineering is currently carried out, regulatory requirements need to be modified to define good engineering practices. The following additions to design controls will help eliminate many design deficiencies: