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.

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