Benchmarking the Pulse Physiology Engine on Various Single-Board Computing Platforms

The power of the open source Pulse physiology platform lies in the ability to simulate whole body patient physiology faster than real-time. Pulse is also a one-stop shop for the various physiology needs of medical device and manikin developers. During our recent attendance at the International Meeting on Simulation in Healthcare (IMSH), we talked with several hardware developers who showed great interest in adding live, validated physiology data from the Pulse engine to their systems. Most of these manufacturers integrate their system controls on a small form factor, and require lean components to run on a single-board computer (SBC) that are portable and use minimal power. The natural question that arises is: How fast does the Pulse physiology engine run on low cost, commercially available SBCs? To this end, we have tested Pulse on various SBC architectures. This blog post reports the results and outlines our plans for the future in supporting various SBCs.

In these tests, we only focused on various boards using an ARM Cortex A series core. Most SBCs utilize this architecture for its the low-power, low-cost option and its ability to drive the computing power necessary for a complex hardware system. In our tests we included a BeagleBone Black with uses the first A-series processor, the A8; an ASUS Tinker Board featuring an A17 processor; an ODROID XU4 with both an A15 and A7 processor; the Raspberry Pi 3B, which features the latest ARM Cortex A53; the DragonBoard 410c backed by Qualcomm’s A53 based SnapDragon processor; and finally the FireFly RK3399 featuring Rockchips implementation of the high performance A72 core. 

For each of these boards, we compiled the Pulse physiology engine (as detailed on our repository) then executed it to simulate 120s of whole body physiology. The Pulse engine executes on a single core and generally uses the same computing resources regardless of how many insults given to the patient, such as a hemorrhage, drugs, or pneumothorax. During this execution, we output the amount of time it took to simulate every 10 seconds of physiology. Our goal is to ensure the engine runs fast enough on these processors so that in conjunction with other components, a hardware system will be able to provide data in real-time or faster to an end user (i.e., simulate 1 second of patient physiology faster than 1 second).

Our goal for this benchmarking was to identify a sampling of ARM cores that target various power and cost points while still being able to maintain faster than real-time calculations of the Pulse physiology engine. The key difference between the ARMv7 and the ARMv8 is that only the ARMv8 supports 64 bit processing. Pulse has been tested and validated in both 32 and 64 bit processes and has shown no discernible difference in physiology results. We did find that the power efficient A53 based boards did meet our real-time requirements in executing Pulse. While the A53 does provide time for things like a network communication processes, it may not provide enough computation power for other complex system components. We feel the A53 provides a minimum system spec for a SBC running only Pulse while the A7 was just not powerful enough to adequately run Pulse at all to be effective in a hardware architecture. The A17 and A72 are the premier ARMv7 and ARMv8 processors respectively, and provide plenty of computational power to execute Pulse at a very high rate as shown in the table.

The results of this analysis show that the Pulse engine allows system designers plenty of options in cost and architecture while designing their systems to be real-time. Kitware will continue to optimize Pulse to improve its performance on SBCs while at the same time testing Pulse on various platforms and operating systems to ensure it can be leveraged in wide-ranging system architectures. Kitware is available to help you customize, design, and integrate Pulse into your application. To learn more about how Kitware can help your development efforts, please contact kitware@kitware.com.