Reverse Architecting of a Medical Device Software


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Reverse Architecting of a Medical Device Software

  1. 1. Architecture Reconstruction and Analysis of Medical Device Software Blood Pressure Monitor CARA SoftwareFraunhofer US FDADharmalingam Ganesan Raoul JetleyMikael Lindvall Paul JonesRance Cleaveland Yi Zhang © 2011 Fraunhofer USA, Inc. Center for Experimental Software Engineering
  2. 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. 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. 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. 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 separatedCARA_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. 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