Almost everyone who uses a mobile phone has experienced several interruptions. Although these products and other consumer products system failure or small problems will bring inconvenience, but they will not cause catastrophic consequences. However, a system failure of medical electronic equipment will bring life-threatening, which is why medical equipment, the devices integrated in these systems and the software running in these devices must pass strict testing and meet the strict requirements of the food and Drug Administration (FDA).
In order to ensure that our new design can achieve ideal and reliable performance and successfully pass the FDA approval process, we adopted a new design called scrum / Sprint development process “is a highly structured design method. In addition, by reducing the functions implemented in the software, it can also reduce the probability of software errors. We have implemented these functions in Xilinx FPGA. In order to fully understand this method, we first analyze the design process of medical equipment.
Three stage life cycle
FDA has formulated strict regulations, requirements and guidelines for medical electronic products to ensure the personal safety of the public. In these regulations, FDA sets strict requirements for the life cycle of medical devices (Figure 1). In general, electronic product companies must meet the above requirements in the following aspects, including all components, spare parts or accessories of medical equipment, any software used in the production process of medical equipment, and all software used in the quality system of equipment manufacturers, such as procedures for recording and maintaining equipment history.
Figure 1. The whole life cycle of medical device design defined by FDA
We can divide the whole life cycle of medical equipment into three main stages. The first stage is the initial stage of the whole product life cycle (Figure 2), which is the worst systematic stage of all three stages. During this stage, enterprises mainly focus on theoretical and conceptual research and development. The duration of this phase varies from weeks to years, which is closely related to the complexity of the system that the enterprise is preparing to develop.
Figure 2. The application of virtual instrument and Hei design method in the early stage of product life cycle can clearly understand the problems to be solved.
Data acquisition and analysis is the basic component of the whole product life cycle in the early stage. Usually, researchers and product design specification teams use a variety of tools to streamline the process. In this stage, Hei usually uses the LabVIEW product of national instruments (Ni) company to adjust the I / O of FPGA. Once we fully understand the problem, we can design a solution. For the device development and prototype design, we combine intuitive graphic programming, reuse mathematics and signal processing functions to develop new algorithms. Then, through the use of commercial hardware suite, we refer to the real world data to verify the performance of the algorithm. In many cases, we can use the FPGA based prototype design platform provided by Ni to realize the final device prototype. Specifically, we can use LabVIEW real time module and FPGA module together with Ni compactrio, so as to quickly achieve iteration between algorithm design and device prototype stage. Using hardware suite for prototype design can not only significantly shorten the time of hardware development and integration, but also enable us to focus more on delivering powerful and reliable software design.
Figure 3. The audit and verification of software design is usually completed in the middle of the product life cycle.
The second stage of the whole life cycle of medical equipment can be called the middle stage of the whole life cycle of the product (see Figure 3), which can fully meet the needs of the designed equipment in terms of productization, verification, audit and manufacturing. The focus of this stage is to develop specification documents with accurate definition and clear quantifiable requirements. Once these specifications are defined, a clear mapping relationship can be established between the specification documents and the actual implementation code.
Figure 4. The traditional “waterfall” development process needs to complete each stage of development before going to the next step.
In today’s complex medical equipment market, customers must speed up the listing and get ahead. Many companies have adopted the traditional “waterfall” development method to complete this work. The design team in the “waterfall” development method needs to complete each step of the design process before going to the next step (Figure 4). Waterfall method highly relies on having complete and accurate specifications at the beginning of the project. However, in the medical equipment market, more often, the demand will continue to develop and change with the development of products. This needs to be able to consider the evolution of the process. Hei’s scrum / sprint development process is an ideal solution to this problem.
Figure 5 – in the “scrum / sprint” process, starting a project requires only high-level system architecture and specifications.
Figure 6 – the project team identifies, expands, and allocates sprint to-do tasks for each sprint in the cycle. The project team then assesses the process at the daily scrum meeting and removes the barriers. The team delivers product functionality to the customer at the end of each sprint.
In the scrum / sprint process, we only require high-level system architecture and specifications to start the project. We subdivided the project into 4-6 weeks of “sprint”. In each “sprint”, we can identify all the tasks that we think the process will require and put them on the burn down list. Figures 5 and 6 show the related flow charts. Hei uses scrum / sprint development process throughout the company, which not only accelerates our development process by 30%, but also enables us to complete the implementation of new products several months in advance. Table 1 compares waterfall development with Scrum / sprint development.
The third and final stage of medical device development is in the later stage of the whole life cycle of the product (Figure 7). This stage requires very little engineering work, but customer feedback and market success will help to promote the concept formation of a new generation of products, so that the life cycle will enter a new cycle.
Figure 7 – the later stage of the product life cycle is to bring the product to market, obtain feedback, and help determine the functions of the new generation of products. This completes the work of this cycle and brings it to a new conception stage.
Using Scrum / Sprint product development process, combined with FPGA based package hardware and advanced FPGA Software Design Tools covering from R & D to manufacturing process, Hei can quickly develop the derivative technology of future products. We found that we can use the common kernel architecture in a variety of product development in many cases. For example, the architecture of pump controller that can adjust IV and infusion pump can also be used in other design projects that can control motor to realize blood transfusion management.
Why hardware is better than software
In order to effectively use this method and further speed up the design process, it is necessary to change the way of conceptual design, that is, from software centered to more hardware centered. As people are aware, medical device recalls reached a new high in 2008, up 43% from 2007. FDA experts believe that there are two main reasons for the recall: defects in raw materials used in production; problems in software development. It is easier for enterprises to manage the quality of raw materials, but it is much more difficult to solve the quality problem of software. With the rapid increase of device software code, the problem will only become more and more serious. The problem is particularly acute after the FDA’s consumer health and safety department said that medical device designers have many safety responsibilities.
In Hei, we think that this problem has a potential solution, but it is not to do more testing, code checking and introduce more processes. On the contrary, we only write as little software as possible and give more logic to hardware components such as Xilinx FPGA. Let’s take a look at the common causes of software failures and how we will use FPGA to solve these problems.
Most modern devices need to be able to handle multiple tasks at the same time, while most embedded processors still have only one processing kernel. This means that the processor can only execute one instruction at a time. At the same time, parallel processing is not that good, because they still have to share the main system CPU. In addition, other shared resources, such as communication drives, hard disks, and user interface components, can also cause deadlocks — two or more processes waiting for each other to release resources.
Deadlock is very difficult to copy and debug because it often depends on multiple processes and requires events to be synchronized in sequence. It is difficult to find most deadlock problems by unit testing. They are often found by code inspectors, skilled system testers, and sometimes by luck.
In contrast, with FPGA, independent processes have their own physical circuit system, so there is no shared resource. When each clock signal reports time, combinational logic not only blocks in each circuit, but also stores relevant values in independent registers. Because the process does not rely on other resources, it will not deadlock. In this way, you can trust the results of simulation and unit test more, because unknown factors such as resource competition are no longer a problem.
When developing embedded software, you don’t need to write every line of code from scratch. There are many tools that can help firmware designers improve their work efficiency, such as simple drivers, network protocol stacks, operating systems, and even code generation tools. Although these systems are usually tested independently, there are still some defects in the software. Due to the variety of combination of tools and libraries, it is very possible to combine components in a new way.
For this reason, FDA requires that all software packages used in medical devices must be verified according to their specific design and usage. What does that mean? For example, if we are using a signal processing library containing fixed-point fast Fourier transform and need to detect the presence of a specific frequency component, we do not need to verify that the FFT will return the correct value for all possible inputs. However, what we need to verify is whether FFT can return the expected value for all valid inputs that conform to the specification. For example, if we only detect the tone that can be heard by the human ear, it is not necessary to test whether the value returned when the input exceeds 20kHz is correct.
However, software components that seem to be independent of each other are not necessarily so. Therefore, if we combine software protocol stack with SPI driver and use it with real-time operating system (RTOS), we need to verify all these components to be confident in FFT. If FFT transfers effective output to SPI driver, but SPI driver fails systematically, the problem is inevitable. Then, if we decide to adjust the SPI driver, we need to verify the entire software stack again. This is very troublesome, and a faulty component will drag down the development process of the whole system. For this reason, in Hei, we try our best to reuse the middleware and RTOS driver combination with good characteristics. For example, we can use the middleware driver on the Rio platform of Ni board.
In addition to verifying the software according to each specific usage, we also need to verify all the third-party intellectual property rights (IP) we use in our FPGA based design. However, once we have completed the verification of all our usage, we will have no doubt that IP will work as expected after integrating with other components. Let’s take a look at our FFT example above. If we use FPGA, we can get or generate FFT core just like using software, and verify the correctness of the number according to each usage. However, the risk of intermittent failures can be greatly reduced because we do not need all the processor middleware required for software centric design. In this way, RTOS and SPI drivers are no longer their own IP cores, because their work will not directly affect FFT. In addition, if we adjust the implementation of SPI driver, we do not need to verify the unaffected part of the system.
Buffer overflow management
Another example of how we can use FPGA to reduce the common errors in software centric systems is buffer overflow management. When a program tries to store more data than the end of the memory allocated for it, it will repeatedly write some adjacent data that should not be written, which will lead to buffer overflow. This is a very difficult defect to detect, because the rewritten memory can be accessed at any time in the future, and this situation may or may not cause obvious errors. A common buffer overflow in embedded design is caused by some high-speed communication, which may come from network, disk or a / D converter. If the communication interruption time is too long, the buffer will overflow, so we need to solve this problem to prevent all kinds of conflicts.
We can use FPGA to manage buffer overflow in two ways. In the first example, we use FPGA to manage cyclic transmission or double buffer transmission, which can unload the load of real-time processor. In this case, FPGA can be used as a coprocessor to reduce the interrupt load of the main processor. This is a general configuration, especially in high-speed A / D converters.
In the second example, we use FPGA as the security layer of the protection function, so that the I / O for the patient passes through FPGA before reaching the processor. In this case, you can add additional security logic to the FPGA, so that when the software on the processor crashes, you can put all the outputs in a known security state. FPGA can play the role of watchdog, and its logic can ensure that the risk to patients is minimized in case of software failure. By introducing FPGA into the main signal chain of the device in the architecture design, you can use one or two of these two methods to deal with buffer overflow, so that you can better deal with it when something happens.
In fact, the more we move the overall system functions of software and hardware to FPGA, the faster we can complete the design process, and ultimately the faster we can complete the verification of our design in the final products of customers. If we can verify the reliability of our design on the overall system more quickly, our customers can verify the entire final product more quickly and then submit it to FDA for approval. This process means that our customers can significantly accelerate the launch process of their products, improve the quality of life of patients, and even save lives.
If we use ASIC technology to implement the design, we need to wait several months for the foundry to produce the hardware. Additional steps such as verifying the physical design of ASIC, creating mask and putting the design into production will result in more errors and defects. If the design error occurs in any of these steps, the result will lead to product launch time is greatly delayed. Since FPGA has been produced and fully tested, we only need to care about our design and software, and ensure that the design can meet the requirements of customers. By fully combining the “scrum / sprint” method, hardware centered concept, using highly reliable tools and choosing FPGA between FPGA and ASIC, we can make customers realize differentiation, and then bring changes to customers, that is, patients.
Editor in charge: CT