Arnab Ray

Architectural interaction diagrams: AIDs for system modeling

This paper develops a modeling paradigm called Architectural Interaction Diagrams, or AIDs, for the high-level design of systems containing concurrent, interacting components. The novelty of AIDs is that they introduce interaction mechanisms, or buses, as first-class entities into the modeling vocabulary. Users then have the capability, in their modeling, of using buses whose behavior captures interaction at a higher level of abstraction than that afforded by modeling notations such as Message Sequence Charts or process algebra, which typically provide only one fixed interaction mechanism. This paper defines AIDs formally by giving them an operational semantics that describes how buses combine subsystem transitions into system-level transitions. This semantics enables AIDs to be simulated; to incorporate subsystems given in different modeling notations into a single system model; and to use testing, debugging and model checking early in the system design cycle in order to catch design errors before they are implemented.

Automatic requirement extraction from test cases

This paper describes a method for extracting functional requirements from tests, where tests take the form of vectors of inputs (supplied to the system) and outputs (produced by the system in response to inputs). The approach uses data-mining techniques to infer invariants from the test data, and an automated-verification technology to determine which of these proposed invariants are indeed invariant and may thus be seen as requirements. Experimental results from a pilot study involving an automotive-electronics application show that using tests that fully cover the structure of the software yield more complete invariants than structurally-agnostic black-box tests.

Validating Automotive Control Software Using Instrumentation-Based Verification

This paper discusses the results of an application of a formally based verification technique, called Instrumentation-Based Verification (IBV), to a production automotive lighting controller. The goal of the study is to assess, from both a tools as well as a methodological perspective, the performance of IBV in an industrial setting. The insights obtained as a result of the project include a refinement of a previously developed architecture for requirements specifications; observations about changes to model-based design workflows; insights into the role of requirements during development; and the capability of automated verification to detect inconsistencies among requirements as well as between requirements and design models.

Generic Safety Requirements for Developing Safe Insulin Pump Software

Background: The authors previously introduced a highly abstract generic insulin infusion pump (GIIP) model that identified common features and hazards shared by most insulin pumps on the market. The aim of this article is to extend our previous work on the GIIP model by articulating safety requirements that address the identified GIIP hazards. These safety requirements can be validated by manufacturers, and may ultimately serve as a safety reference for insulin pump software. Together, these two publications can serve as a basis for discussing insulin pump safety in the diabetes community. Method: In our previous work, we established a generic insulin pump architecture that abstracts functions common to many insulin pumps currently on the market and near-future pump designs. We then carried out a preliminary hazard analysis based on this architecture that included consultations with many domain experts. Further consultation with domain experts resulted in the safety requirements used in the modeling work presented in this article. Results: Generic safety requirements for the GIIP model are presented, as appropriate, in parameterized format to accommodate clinical practices or specific insulin pump criteria important to safe device performance. Conclusion: We believe that there is considerable value in having the diabetes, academic, and manufacturing communities consider and discuss these generic safety requirements. We hope that the communities will extend and revise them, make them more representative and comprehensive, experiment with them, and use them as a means for assessing the safety of insulin pump software designs. One potential use of these requirements is to integrate them into model-based engineering (MBE) software development methods. We believe, based on our experiences, that implementing safety requirements using MBE methods holds promise in reducing design/implementation flaws in insulin pump development and evolutionary processes, therefore improving overall safety of insulin pump software.

Unit verification: the CARA experience

The computer-aided resuscitation algorithm, or CARA, is part of a US Army-developed automated infusion device for treating blood loss experienced by combatants injured on the battlefield. CARA is responsible for automatically stabilizing a patient’s blood pressure by infusing blood as needed based on blood pressure data the CARA system collects. The control part of the system is implemented in software, which is extremely safety critical and thus must perform correctly .This paper describes a case study in which a verification tool, the Concurrency Workbench of the New Century (CWB-NC), is used to analyze a model of the CARA system. The huge state space of CARA makes it problematic to conduct traditional “push-button” automatic verification such as model checking. Instead, we develop a technique called unit verification, which entails taking small units of a system, putting them in a “verification harness” that exercises relevant executions appropriately within the unit, and then model checking these more tractable units. For systems like CARA whose requirements are localized to individual system components or interactions between small numbers of components, unit verification offers a means of coping with huge state spaces.

Using Sequence Diagrams to Detect Communication Problems between Systems

Many software systems are evolving complex system of systems (SoS) for which inter-system communication is both mission-critical and error-prone. Such communication problems ideally would be detected before deployment. In a NASA-supported Software Assurance Research Program (SARP) project, we are researching a new approach addressing such problems. In this paper, we show that problems in the communication between two systems can be detected by using sequence diagrams to model the planned communication and by comparing the planned sequence to the actual sequence. We identify different kinds of problems that can be addressed by modeling the planned sequence using different level of abstractions.

Security Assurance Cases for Medical Cyber–Physical Systems

With cybersecurity increasingly becoming a focus of regulatory concern, both medical device manufacturers and regulators are facing another challenge: how to establish, and also demonstrate, that the devices are also secure. This paper outlines an approach to constructing assurance cases to capture assumptions about the attacker by 1) identifying the hazards of interest to attacker; 2) identifying attack surfaces; 3) enumerating vulnerabilities and attack scenarios; and 4) ranking attack scenarios on the basis of a risk model. Introducing the security considerations early in the design cycle, we can better integrate security with existing engineering processes to yield documents that both improve the engineering processes and are acceptable for regulatory oversight.

Model-Based Engineering for Medical-Device Software

This paper demonstrates the benefits of adopting model-based design techniques for engineering medical device software. By using a patient-controlled analgesic (PCA) infusion pump as a candidate medical device, the authors show how using models to capture design information allows for i) fast and efficient construction of executable device prototypes ii) creation of a standard, reusable baseline software architecture for a particular device family, iii) formal verification of the design against safety requirements, and iv) creation of a safety framework that reduces verification costs for future versions of the device software. 1.

Constructing safety assurance cases for medical devices

This paper lays out a approach for safety assurance case argumentation. The approach links together in a principled manner a devices highest-level safety claims, operating environments and hazards; and its safety requirements, final implementation, and test and other validation results. This approach is intended for the creation of safety assurance cases for pre-market submissions to a regulatory authority like the Food and Drug Administration.

Assurance Cases: Their Use Today and The Challenges Ahead

Arnab Ray is a research scientist at the Fraunhofer Center for Experimental Software Engineering at the University of Maryland. E-mail: ARay@fc-md.umd.edu An assurance case may be looked upon as a documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given environment. Assurance cases, as a concept, are not particularly new. They have been used for many years to construct safety arguments for safety critical systems such as those in the aerospace, nuclear, and transportation industries. However, their use in medical device premarket submissions for infusion pumps has been fairly recent, brought about, to a large extent, by their inclusion in a recent infusion pump guidance document under a pilot program of the U.S. Food and Drug Administration (FDA). This article examines what an assurance case is, a few of the challenges behind assurance case development in a regulatory context for device software, and the ways in which these challenges may be handled.