Alarms

URL

Change Log

When What
September 21st, 2015 Donated by Gregory Gay

Reference

Studies who have been using the data (in any form) are required to include the following reference:

@misc{alarms
author = {Anitha Murugesan, Gregory Gay, Sanjai Rayadurgam, Mats Heimdahl },
title = {Alarms Model and Testing Data},
howpublished= {\url{http://crisys.cs.umn.edu/PublicDatasets.shtml}}
@ARTICLE{7081779,
author={Gay, G. and Staats, M. and Whalen, M. and Heimdahl, M.P.E.},
journal={Software Engineering, IEEE Transactions on},
title={The Risks of Coverage-Directed Test Case Generation},
year={2015},
volume={41},
number={8},
pages={803-819},
keywords={program testing;risk management;software fault tolerance;automated test generation tools;counterexample-based test generation;coverage criteria satisfaction;coverage-directed test case generation;critical systems;fault detection;fault finding effectiveness;observable MC/DC;program structure;random generation approach;random test suites;risks;software testing;structural coverage criteria;system structure;test automation;test oracle selection;Aerospace electronics;Fault detection;Measurement;NASA;Software packages;Standards;Testing;Software Testing;Software testing;System Testing;system testing},
doi={10.1109/TSE.2015.2421011},
ISSN={0098-5589},
month={Aug},}

About the Data

Overview of Data

Infusion pumps are medical cyber physical systems used for controlled delivery of liquid drugs into a patient’s body according to a physician’s prescription (the set of instructions that governs infusion rates for a medication). These pumps may be classified into various kinds depending on their features, construction, and usage. Patient-Controlled Analgesia (PCA) pumps are generally equipped with a feature that allows patients to self-administer a controlled amount of drug (a patient-bolus), typically a pain medication.

In an infusion system, the clinician operates the GPCA device, programs the prescription information, loads the drug, connects the device with the patient, and responds to exceptional conditions that occur during the therapy. The patient receives the medication from the device through an intravenous needle. The patient can self-administer prescribed amounts of additional drug by requesting a bolus, a request usually done by pressing a bolus request button accessible at the patient’s bed. The hospital pharmacy database is a repository that stores manufacturer provided drug information (for example, upper limits on infusion rates for a specific drug).

In short, the GPCA system has three primary functions: (1) deliver the drug based on the prescribed schedule and patient requests, (2) prevent hazards that may arise during its usage, and (3) monitor and notify the clinician of any exceptional conditions encountered.

This package contains a model of the alarm management behavior of the software of an infusion pump, a version of the model with read faults, a set of seeded mutants, and associated test inputs used for model-based testing research.

For more information on this model, please see: Anitha Murugesan, Michael Whalen, Sanjai Rayadurgam and Mats Heimdahl. Compositional Verification of a Medical Device System. Accepted at High Integrity Language Technology Accepted at High Integrity Language Technology, Pittsburg, Nov 2013

Paper Abstract

A number of structural coverage criteria have been proposed to measure the adequacy of testing efforts. In the avionics and other critical systems domains, test suites satisfying structural coverage criteria are mandated by standards. With the advent of powerful automated test generation tools, it is tempting to simply generate test inputs to satisfy these structural coverage criteria. However, while techniques to produce coverage-providing tests are well established, the effectiveness of such approaches in terms of fault detection ability has not been adequately studied. In this work, we evaluate the effectiveness of test suites generated to satisfy four coverage criteria through counterexample-based test generation and a random generation approach-where tests are randomly generated until coverage is achieved-contrasted against purely random test suites of equal size. Our results yield three key conclusions. First, coverage criteria satisfaction alone can be a poor indication of fault finding effectiveness, with inconsistent results between the seven case examples (and random test suites of equal size often providing similar-or even higher-levels of fault finding). Second, the use of structural coverage as a supplement-rather than a target-for test generation can have a positive impact, with random test suites reduced to a coverage-providing subset detecting up to 13.5 percent more faults than test suites generated specifically to achieve coverage. Finally, Observable MC/DC, a criterion designed to account for program structure and the selection of the test oracle, can-in part-address the failings of traditional structural coverage criteria, allowing for the generation of test suites achieving higher levels of fault detection than random test suites of equal size. These observations point to risks inherent in the increase in test automation in critical systems, and the need for more research in how coverage criteria, test generation approaches, the test oracle use- , and system structure jointly influence test effectiveness.