Most medical electronic systems now depend on combinations of hardware and software, forming elaborate mechatronic systems that both monitor and regulate patient health metrics. To manage mechatronic challenges, product designs must seamlessly integrate embedded and application software, analog and digital hardware, and mechanical components. Unfortunately, successfully integrating and verifying complex systems is often costly in terms of time, money, and engineering resources.

Fig. 1 – The V-Diagram is one of the most common ways to express a system design process.
The FDA requires that medical device designers and manufacturers adhere to the FDA Good Manufacturing and Design Practices (GMP). As part of this process, the FDA requires that the final “as shipped” system configuration be verified to meet the requirements and validated against the intended function, and of course, be safe. The process begins with a requirements-driven system definition and proceeds into a preliminary design or architecture phase, which feeds into designing and implementing the components that make up the system. Once these are implemented, they are verified proceeding in succession until the candidate production system is integrated and tested. This is typically visualized in the “V” diagram.

This is an inherently sequential process where verification and validation is not complete until the end, as the “time” axis indicates (Fig. 1). Since regulation does not permit any substitute for final “serial #0” physical system verification and validation, most companies have tried to implement the V process with the goal of minimizing the time from design to physical realization. Writing requirements down in a document based on previous experience and expert knowledge is viewed as faster than creating a behavioral model of the requirements, executing them, and performing simulations and dynamic analysis.

The result is a “paper”-driven, frontend process. The requirements and system architectures are done on “paper” elements such as documents, static diagrams, and requirement lists, which of course are electronically created, stored, indexed, and linked, but are not qualitatively different from what was done many decades ago with a pencil, ruler, typewriter, and paper. A complete analysis and virtual simulation of the entire complex system is not undertaken, as it is viewed as too time-consuming, and efforts are focused on getting to an early physical prototype quickly.

With this approach, the first real visibility of complex system integration problems is reserved for the very final stage of the process — testing the physical, integrated system. The traditional paper-based approach to implementing the V process may have served companies well in the past; however, with today's complex system developments of integrated, interrelated mechatronic elements interacting in non-obvious ways, this is no longer a viable option. A single unplanned redesign caught at the physical integration stage can extend the schedule drastically. The more complex the system, the less likely this approach will result in an FDAapproved design, developed within schedule and budget.

Imagine instead a process where concepts and requirements from all disciplines could be easily tested from the very start, using software modeling techniques and, once proven, would pass from step to step in the process. Teams of experts would work concurrently throughout the technical, system, and process levels, with individual designers concentrating on their specific tasks using the best available tools, while still being able to seamlessly fit into a complete virtual system environment.

Verification would proceed in parallel with design occurring at first completely virtually; then these same virtual tests would be reused when the system is physically verified. Monitoring of compliance with regulatory standards would be integral to every step. Ultimately, all the pieces would be efficiently integrated into a system that works the first time and does not need physical redesigns. This is the vision that gave rise to the innovative Model Driven Development (MDD) tools and processes that are fast gaining favor among system developers. MDD lays the groundwork for an integrated design flow that addresses the complexity challenge once and for all.

The Model Driven Development Approach

Fig. 2 – The modified V process with a Model Driven Development flow.
So how does MDD help move a development program from sequential design and verification to a concurrent process? It does it by replacing paper-based static documents with a dynamic data-centered approach. The whole process is driven by the data, which is always synchronized with the current stage of development. Many companies understand the importance of requirements, but too often, requirements are kept in documents or databases that exist outside the everyday world of the designers. When changes occur in a requirement, this may or may not be communicated effectively to the design or verification teams. This is a common struggle and a cause of many problems that are often not found until final testing.

« Start Prev 1 2 3 Next End»