Reverse Architecting of a Medical Device Software
Download as PPTX, PDF0 likes539 views
This document describes a method developed by Fraunhofer to reconstruct the as-built architecture of medical device software. The method discovers both static and runtime architectural structures from source code to help the FDA analyze software for safety issues during regulatory reviews when only documents and test results are submitted, not source code. It addresses FDA needs like identifying unsafe code constructs and assessing testability and safety. Sample outputs show tasks, communication, and module dependencies. The method formalizes the reconstruction using graph relations to aid static analysis tool usage and safety assurance cases.
Reverse Architecting of a Medical Device Software
- 1. Architecture Reconstruction and Analysis of Medical Device Software Blood Pressure Monitor CARA Software Fraunhofer US FDA Dharmalingam Ganesan Raoul Jetley Mikael Lindvall Paul Jones Rance Cleaveland Yi Zhang © 2011 Fraunhofer USA, Inc. Center for Experimental Software Engineering
- 2. Context • FDA reviews 510k pre-market submissions for safety of medical devices – Hazard analysis, arch. docs, and test results are reviewed, but not source code – (may) review code if failures are reported in field • Submitted arch. docs are typically “too abstract” – not easy to analyze for safety • What (as-built) architectural viewpoints are needed for safety and assurance cases? © 2011 Fraunhofer USA, Inc. Center for Experimental Software Engineering
- 3. Software analysis needs at FDA • Basic needs: identify unsafe constructs (enough) • Safety “requires” good engineering – What is the as-built architecture of the software? – Is the architecture based on good engineering? • Good modular structure? Good separation of concerns? • Safety “requires” extensive testing – Was the medical device software tested enough? (can’t answer) • Easy to test unit-by-unit? • Easy to verify using static analysis tools (SATs)? • Developed a method to address these questions – Discovers static and runtime structures from code – These structures are abstract, yet concrete and precise © 2011 Fraunhofer USA, Inc. Center for Experimental Software Engineering
- 4. Brief overview of the method • Premise: As-built architecture is inspired and influenced by external entities – (e.g., libraries, COTS software) used by the software – Grounded on analysis of more than 2 dozen industrial systems • A knowledge base (KB) of keywords (e.g., “taskSpawn”, “msgQSend”) support the discovery of architectural structures hidden in source code • Code relations (e.g., call, import) are extracted and then a suite of architectural structures is discovered from different viewpoints using the KB • Discovered runtime structures cover different viewpoints including: – Partition of modules into tasks, Task Spawn, Inter-task communication and synchronization • Discovered structures are used to reason about testability and safety issues • Architecture reconstruction algorithms are formalized using relational operators (e.g., transitive closure, composition) for task-oriented architectures – see the paper © 2011 Fraunhofer USA, Inc. Center for Experimental Software Engineering
- 5. Sample outputs of the method Alarm_Svc Some good design principles in place: B2B_Broker Separate task for I/O bound function Separate task for periodic function (e.g., CUII_Svc collecting blood pressure beat-to-beat) CUII_MSGQ However, coordination and computation are not separated CARA_Main Communication channels not abstracted Synchronization mechanism not abstracted CARA_MSGQ Task1 … Task7 CARA_Main Task9 Task10 Task11 Legend Log_Svc Task LOGQ Entry Point cara_interface.c cara_main.c file9.c file10.c file11.c DSPQ Display_Svc Entry points for multiple tasks in one module Task file2.c file22.c Compiled object file has source code of many tasks Uses/requires Static module structure lacks separation of concerns Legend Leads to testability issues Task2 Unit testing/verification is not easy (if not impossible) file3.c file33.c Task specific code and shared modules, types, file1.c file11.c global variables were discovered Used for unit-by-unit verification using SATs util.c Task3 Task1 © 2011 Fraunhofer USA, Inc. Center for Experimental Software Engineering
- 6. Closing remarks • Need as-built architecture to configure SATs and interpret their detailed output • Some issues with SATs – Wrongly reported several entry functions as dead – OS functions for messaging not taken care properly • SATs are useful but cannot be used right out of the bat • Analysis of as-built architecture offers complementary design insights for safety analysis • Future Work: – Link safety requirements to discovered structures for an assurance case – Evolve the catalog of structures for testability and safety – Discover behavioral models for verification of safety properties © 2011 Fraunhofer USA, Inc. Center for Experimental Software Engineering