Docstoc

frs

Document Sample
frs Powered By Docstoc
					 Neutrino Engineering Mode Tester Plus
Functional Requirement Specification (FRS)




  PN#TBD      St. Jude Medical Confidential   October 16, 2011
                    St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.



TABLE OF CONTENTS
TABLE OF REQUIREMENTS                                                                          IV

1.      INTRODUCTION                                                                               1

 1.1.    Purpose                                                                                    1

 1.2.    Scope and Overview                                                                         1

 1.3.    Definitions, Acronyms, and Abbreviations                                                   1

 1.4.    References                                                                                 3

 1.5.    Conventions                                                                                3


2.      GENERAL DESCRIPTION                                                                        4

 2.1.    Product Perspective                                                                        4

 2.2.    Product Functions                                                                          4

 2.3.    User Characteristics                                                                       5

 2.4. General Constraints                                                                           5
    2.4.1. Standards Compliance                                                                     5
    2.4.2. Hardware Limitations                                                                     5
    2.4.3. Software Limitations                                                                     6

 2.5.    Assumptions and Dependencies                                                               6

 2.6.    Goals                                                                                      6


3.      FUNCTIONAL REQUIREMENTS                                                                    8

 3.1.    Overview                                                                                   8

 3.2. Common Requirements                                                                           8
    3.2.1. Coordination                                                                             8
    3.2.2. Error Handling                                                                           9
    3.2.3. Inputs                                                                                  10
    3.2.4. Outputs                                                                                 10
    3.2.5. Commands                                                                                11
    3.2.6. Data                                                                                    16
    3.2.7. Performance and Timing                                                                  16
    3.2.8. Constraints                                                                             16
    3.2.9. Dependencies                                                                            17

 3.3.    Neutrino Engineering Programmer                                                           18

 3.5.    Heart Simulator                                                                           21

        PN#TBD           St. Jude Medical Confidential      October 16, 2011              Page i
                  St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.6. Direct Digital Player                                                                    21
   3.6.1. Inputs                                                                              21
   3.6.2. Outputs                                                                             21
   3.6.3. Commands                                                                            21
   3.6.4. Data                                                                                25
   3.6.5. Performance and Timing                                                              25
   3.6.6. Constraints                                                                         26
   3.6.7. Dependencies                                                                        26

Digital Outputs                                                                               26
  3.8.1.   Inputs                                                                             26
  3.8.2.   Outputs                                                                            26
  3.8.3.   Commands                                                                           28
  3.8.4.   Data                                                                               29
  3.8.5.   Performance and Timing                                                             29
  3.8.6.   Constraints                                                                        29
  3.8.7.   Dependencies                                                                       29

3.9. Digital Inputs                                                                           29
   3.9.1. Inputs                                                                              29
   3.9.2. Outputs                                                                             32
   3.9.3. Commands                                                                            32
   3.9.4. Data                                                                                36
   3.9.5. Performance and Timing                                                              37
   3.9.6. Constraints                                                                         38
   3.9.7. Dependencies                                                                        38

3.10.      Logic Analyzer Communication                                                       39
   3.10.1.     Inputs                                                                         39
   3.10.2.     Outputs                                                                        39
   3.10.3.     Commands                                                                       39
   3.10.4.     Data                                                                           41
   3.10.5.     Performance and Timing                                                         41
   3.10.6.     Constraints                                                                    41
   3.10.7.     Dependencies                                                                   42

Breadboard Address Recorder (BAR) Communication                                               42
  3.12.1.   Inputs                                                                            42
  3.12.2.   Outputs                                                                           43
  3.12.3.   Commands                                                                          43
  3.12.4.   Data                                                                              45
  3.12.5.   Constraints                                                                       45

3.13.      Digital Activity Sensor                                                            45
   3.13.1.      Inputs                                                                        46
   3.13.2.      Outputs                                                                       46
   3.13.3.      Commands                                                                      46
   3.13.4.      Data                                                                          47
   3.13.5.      Performance and Timing                                                        47
   3.13.6.      Constraints                                                                   47

3.14.      Clip File Player                                                                   48
   3.14.1.      Inputs                                                                        48
   3.14.2.      Outputs                                                                       48
   3.14.3.      Commands                                                                      48

    PN#TBD              St. Jude Medical Confidential     October 16, 2011              Page ii
                     St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


     3.14.4.     Data                                                                             52
     3.14.5.     Performance and Timing                                                           53
     3.14.6.     Constraints                                                                      53

 3.15.      Test Controller                                                                       53
    3.15.1.      Time Synchronization                                                             53
    3.15.2.      Error Handling                                                                   53
    3.15.3.      Supervision                                                                      54
    3.15.4.      Inputs                                                                           54
    3.15.5.      Outputs                                                                          56
    3.15.6.      Commands                                                                         56
    3.15.7.      Data                                                                             57
    3.15.8.      Performance and Timing                                                           58
    3.15.9.      Dependencies                                                                     58


4.      PERFORMANCE REQUIREMENTS                                                                 58

 4.1.     Overview                                                                                58

 4.2.     Requirements                                                                            58

 4.3.     Dependencies                                                                            59


5.      EXTERNAL INTERFACE REQUIREMENTS                                                          59

 5.1. Hardware Interface                                                                          59
    5.1.1. Overview                                                                               59
    5.1.2. Requirements                                                                           60
    5.1.3. Operation                                                                              61
    5.1.4. Dependencies                                                                           61

 5.2. User Interface                                                                              61
    5.2.1. Overview                                                                               61
    5.2.2. Requirements                                                                           61




        PN#TBD            St. Jude Medical Confidential      October 16, 2011              Page iii
               St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


Table of Requirements
  Functional                          COM_135              18             DAS_39               50
    BRC_07              45            COM_137              18             DAS_41               50
    BRC_09              46            COM_139              18             DAS_43               50
    BRC_11              46            COM_141              18             DAS_45               50
    BRC_13              46            COM_15               10             DAS_60               50
    BRC_14              46            COM_17               11             DAS_61               51
    BRC_15              46            COM_19               12             DAS_63               51
    BRC_17              46            COM_21               12             DDP_05               20
    BRC_19              46            COM_23               12             DDP_11               20
    BRC_21              47            COM_25               12             DDP_13               20
    BRC_23              47            COM_27               12             DDP_15               20
    BRC_25              47            COM_29               12             DDP_17               20
    BRC_27              47            COM_31               12             DDP_19               21
    BRC_29              48            COM_33               12             DDP_21               21
    BRC_31              48            COM_35               13             DDP_22               21
    CFP_10              52            COM_43               13             DDP_23               21
    CFP_20              52            COM_45               13             DDP_24               22
    CFP_21              52            COM_47               13             DDP_25               22
    CFP_22              52            COM_49               13             DDP_28               22
    CFP_23              53            COM_53               13             DDP_29               22
    CFP_24              53            COM_55               13             DDP_30               22
    CFP_25              53            COM_57               14             DDP_31               22
    CFP_26              53            COM_58               14             DDP_35               22
    CFP_30              54            COM_59               14             DDP_37               22
    CFP_31              54            COM_61               14             DDP_39               23
    CFP_32              55            COM_63               14             DDP_41               23
    CFP_33              55            COM_65               14             DDP_43               23
    CFP_34              55            COM_67               14             DDP_45               23
    CFP_36              55            COM_69               14             DDP_46               23
    CFP_38              55            COM_71               15             DDP_47               23
    CFP_40              55            COM_72               15             DDP_51               23
    CFP_50              55            COM_73               15             DDP_53               24
    CFP_60              56            COM_75               15             DDP_55               24
    CFP_61              56            COM_77               15             DDP_57               24
    CFP_62              56            COM_79               15             DDP_59               24
    CFP_71              57            COM_81               15             DDP_61               24
    COM_03               9            COM_82               16             DDP_77               24
    COM_04               9            COM_83               16             DDP_79               25
    COM_09              10            COM_85               16             DDP_81               25
    COM_10              10            COM_86               16             DDP_82               25
    COM_101             17            COM_87               16             DDP_83               25
    COM_103             18            COM_89               16             DDP_85               26
    COM_105             18            COM_91               16             DDP_87               26
      19                              COM_95               16             DDP_97               26
      19                              COM_97               16             DDP_99               26
    COM_11              10            COM_99               17             DI_03                31
    COM_111             19            DAS_15               49             DI_05                31
    COM_121             17            DAS_21               49             DI_07                32
      17                              DAS_25               49             DI_09                32
    COM_125             17            DAS_27               49             DI_105               40
    COM_127             17            DAS_29               49             DI_107               40
    COM_131             17            DAS_35               50             DI_108               40
    COM_133             17            DAS_37               50             DI_109               40

    PN#TBD          St. Jude Medical Confidential      October 16, 2011              Page iv
            St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


DI_11                32           DI_99                 40           TST_09             57
DI_121               34           DO_05                 27           TST_101            63
DI_123               34           DO_07                 27           TST_103            63
DI_125               35           DO_09                 27           TST_109            64
DI_127               35           DO_11                 27           TST_15             58
DI_13                32           DO_13                 27           TST_17             58
DI_131               35           DO_15                 27           TST_19             58
DI_15                33           DO_17                 27           TST_21             58
DI_17                33           DO_19                 28           TST_23             58
DI_19                33           DO_21                 28           TST_25             59
DI_21                33           DO_23                 28           TST_29             59
DI_23                33           DO_25                 28           TST_31             59
DI_25                33           DO_27                 28           TST_33             59
DI_27                33           DO_29                 28           TST_35             59
DI_29                33           DO_31                 28           TST_37             60
DI_31                33           DO_33                 28           TST_39             60
DI_33                33           DO_34                 29           TST_45             60
DI_35                34           DO_35                 29           TST_47             60
DI_37                34           DO_37                 29           TST_49             60
DI_38                34           DO_38                 29           TST_51             60
DI_39                34           DO_39                 29           TST_53             60
DI_41                34           DO_41                 29           TST_55             60
DI_42                34           DO_43                 29           TST_61             60
DI_43                35           DO_45                 30           TST_63             60
DI_45                35           DO_47                 30           TST_65             61
DI_47                35           DO_49                 30           TST_67             61
DI_49                35           DO_51                 30           TST_69             61
DI_51                35           DO_55                 30           TST_71             61
DI_53                35           EP_03                 19           TST_73             61
DI_54                35           HS_03                 20           TST_75             61
DI_56                36           LAC_03                41           TST_77             61
DI_57                36           LAC_05                42           TST_79             62
DI_59                36           LAC_07                42           TST_81             62
DI_61                36           LAC_11                42           TST_83             62
DI_62                36           LAC_13                42           TST_85             62
DI_63                36           LAC_15                42           TST_87             62
DI_65                36           LAC_17                42           TST_89             62
DI_67                36           LAC_21                42           TST_92             62
DI_69                37           LAC_23                43           TST_93             62
DI_71                37           LAC_27                43           TST_95             63
DI_73                37           LAC_29                43           TST_97             63
DI_75                37           LAC_31                43           TST_99             63
DI_77                37           LAC_33                43         Hardware
DI_78                38           LAC_35                43           HW_03              65
DI_79                38           LAC_37                43           HW_05              65
DI_81                38           LAC_39                44           HW_06              65
DI_83                38           LAC_43                44           HW_07              65
DI_85                38           LAC_45                44           HW_09              66
DI_87                38           LAC_46                44           HW_11              66
DI_88                39           LAC_47                44           HW_13              66
DI_89                39           LAC_48                44           HW_14              66
DI_91                39           LAC_50                44           HW_15              66
DI_93                39           TST_03                57           HW_17              66
DI_95                39           TST_05                57           HW_41              66
DI_97                40           TST_07                57           HW_45              66

   PN#TBD            St. Jude Medical Confidential      October 16, 2011          Page ii
                 St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


  HW_49                   66
  HW_51                   66
  HW_53                   66
  HW_61                   66
  HW_67                   67
  HW_69                   67
  HW_71                   67
  HW_79                   67
  HW_81                   67
Performance
  PER_03                  64
  PER_05                  64
  PER_06                  64
  PER_09                  64
  PER_11                  65
User Interface
  UI_03                   67
  UI_05                   68
  UI_07                   68
  UI_09                   68
  UI_11                   68
  UI_13                   68
  UI_14                   68
  UI_16                   68
  UI_19                   69
  UI_25                   69
  UI_29                   69
  UI_31                   69




       PN#TBD             St. Jude Medical Confidential      October 16, 2011          Page iii
                     St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.




1.        Introduction
1.1.      Purpose
          The purpose of this document is to define the functional and interface control requirements of the
          Neutrino Engineering Mode Tester Plus (Neutrino EMT+ for short).

          This document is the complete specification for the operation of the Neutrino Engineering Mode
          Tester Plus and is intended as the driving document for the analysis and design of this system.
          This document assumes knowledge of the Scout and Neutrino hardware/firmware, but specific
          limitations that are important for the understanding of the Neutrino EMT+'s operation are repeated
          here.

1.2.      Scope and Overview
          The scope of the Neutrino Engineering Mode Tester Plus (Neutrino EMT+) project is an
          expansion of the Scout Engineering Mode Tester (Scout EMT), from both the requirements
          perspective and the technology improvement perspective. On the requirements side, new
          features of the Neutrino device shall be exercised. On the technology side, system limitations
          shall be addressed.

1.3.      Definitions, Acronyms, and Abbreviations
Application Programming Interface (API): A function call interface that provides programmers access to a
             system’s capabilities.
Arrhythmia: Irregularity or abnormal rhythm of the heart beat.
Breadboard Address Recorder (BAR): A device which is connected between the breadboard ICD and a
           logic analyzer to record all accesses to ICD addresses. The BAR is primarily used as a code
           coverage tool.
Binning: The process of assigning analog (continuous) measurements into discrete (digital) bins.
Blocking Operating Mode: A mode where execution in the Test Controller is suspended while it waits for
            an action to complete in a functional interface. There are three ways to end a blocking
            operating mode: 1) completion of the action in the functional interface, 2) timeout by the Test
            Controller, and 3) user abort.
CLP File:     An binary file produced by the EGM Tool Set Editor that contains all the information to
              reproduce an EGM waveform. A CLP file is often referred to as a clip file.
Command: A user request for the system to perform some action. A command is either handled directly
          by the Test Controller or converted by the Test Controller into an event destined for a
          functional interface. Commands also map into steps.
DAC:          Digital to analog converter.
Defibrillation (Defib): The arrest of fibrillation of the cardiac muscle (atrial or ventricular) with restoration of
               the normal rhythm using a high voltage shock.
Device:       A St Jude implantable defibrillator or breadboard.
Electrogram (EGM): The electrical activities of the heart as seen by the implanted device. Other
            abbreviations for electrogram are ECG, EKG, and IEGM.
Engineering Mode Tester (EMT): The system, described by this document, which stimulates the ICD and
            observes its responses.




        PN# TBD              St. Jude Medical CRMD Confidential          October 16, 2011           Page 1
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


Engineering Programmer (EP): A system which communicates with the ICD over a telemetry link. The
            Engineering Programmer operates both as an independent system and as a functional
            interface of the EMT.
Episode:        An incident of high rate detection by the device which exists when therapy is initiated by the
                device. An episode is defined to begin when the Interval Average is in the non-sinus range,
                and to end when sinus rhythm is diagnosed, a Commanded Shock is initiated, or device
                programming occurs. An episode is accompanied by diagnostics and, typically, a stored
                electrogram event(s).
Event:       Used in the OOA sense. Events are sent to objects in the Test Controller and functional
               interfaces to cause actions to be performed.
First-In First-Out (FIFO): A queueing order in which the first item entered in the queue is the first one
               processed.
Flex Port:      A port within the Digital Inputs functional interface that is used to monitor data at addresses
                within the ICD.
Functional Interface: A slave unit within the EMT that performs the actions directed to it by the Test
             Controller.
Happening: A term for the event when a set of user-defined conditions are met.
Heart Simulator (HS): A system which generates analog output signals to the ICD. The Heart Simulator
            operates both as an independent system and as a functional interface of the EMT.
Implantable Cardioverter/Defibrillator (ICD): the implanted defibrillator device.
Input Happening: A happening triggered by input signals into the EMT.
Local Area Network (LAN): A network connecting machines that are not widely distributed.
Non-Blocking Operating Mode: A mode where execution in the Test Controller continues while it waits for
            an action to complete in a functional interface.
Object Oriented Analysis (OOA): A method for analyzing a system into objects which communicate via
             events. In particular, the Shlaer-Mellor method is used for the Neutrino EMT+.
Operating Mode: A mode where a slave functional interface performs an extended task while other system
            operations are allowed to continue. Common operating modes include output signal
            generation, peak detection, and wait loop. Operating modes can be blocking or non-
            blocking.
Output Happening: A happening triggered by output signals generated by the EMT.
Output Signal Generation: An operating mode where the a functional interface within the EMT generates
            sequences of analog signals destined for the ICD. Output signal generation is non-blocking.
Peak Detection: An operating mode where a functional interface within the EMT continuously detects and
            logs pacing or high voltage peaks. Peak detection is non-blocking.
Stage Buffer: An area of memory where a waveform is loaded before being played out by I/O hardware.
Step:        The atomic unit of execution.
Test:        A collection of steps used to perform a sequence of user-specified operations. A Test shall
                always begin with the Prepare For Test and Wait For Reset commands/steps. One or more
                user-specified operations occur in the middle, followed by a Finish Step command/step.
Twiddle: The act of setting a Digital Output line to a specified state (0/1).
Test Controller: The master of EMT execution which processes each command and tells functional
             interfaces what actions to perform.
Track:          A “Track” is any portion of a clip (including an entire clip) that is selected for playback. A
                “Track” is defined by a time slice across all channels, but the channels in the time slice can

         PN# TBD             St. Jude Medical CRMD Confidential         October 16, 2011         Page 2
                    St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


              be mapped to any DAC output channel. (i.e. A clip has 8 channels, the DAC output has 2
              channels; any 2 of the 8 channels in the clip time slice can be mapped to the 2 DAC output
              channels.)
Wait Loop: An operating mode where a functional interface within the EMT continuously waits for a
            happening. A wait loop can be either a blocking or a non-blocking operating mode.


1.4.    References
         1.  Ventritex #4100406, Functional Requirements Specification, Scout Engineering Mode
             Tester.
         2. Ventritex #4001304, Project Profile, Scout Engineering Mode Tester - dated 1/26/96.
         3. Ventritex #TBD, Neutrino Implantable Defibrillator - System Specification.
         4. PN #TBD, Heart Simulator - Functional Requirements Specification.
         5. Pacesetter #6300-P1314, Scout Programmer DTM to Host Telemetry Software Interface
             Specification.
         6. Neutrino Engineering Mode Tester – Interface Module Specification, dated TBD.
         7. #TBD, Neutrino Software Requirements Specification.
         8. #TBD, Neutrino Hardware Requirements Specification.
         9. #TBD, Neutrino Bus Address Recorder Functional Requirement Specification.
         10. #TBD, Neutrino Engineering Mode Tester – User’s Guide
1.5.    Conventions
         1.    Statements preceded by a requirement label, such as “COM_38:”, are presented as
               testable requirements. The associated labels serve as links to the FVS for traceability and
               for the assessment of test coverage.
         2.    Inputs and outputs are discussed with respect to the Neutrino EMT+, NOT the ICD under
               test nor other external equipment. The term “input” refers to input into the Neutrino EMT+.
               The term “output” refers to output from the Neutrino EMT+.




       PN# TBD             St. Jude Medical CRMD Confidential      October 16, 2011         Page 3
                  St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


2. General Description
2.1.   Product Perspective
       The Neutrino Engineering Mode Tester Plus (EMT+) is an automated test execution and data
       acquisition system. Its primary purpose is to functionally exercise and validate Implantable
       Cardioverter/Defibrillator (ICD) device software. This version of the Mode Tester will be designed
       specifically to exercise the Neutrino ICD.

       The term "Mode Tester" comes historically from the pacemaker industry. A system used in
       production to verify performance by exercising each of a device's operating modes became
       known as a mode tester. We have extended this concept and applied it specifically to the
       software embedded in our ICD products. The Neutrino EMT Plus specified in this FRS provides a
       set of outputs that can be used in combination to exercise a wide range of "modes" for the
       embedded software. It also monitors and records inputs from the ICD to capture the ICD
       software's behavior.

       The Neutrino EMT+ provides for controlled interaction between its inputs and outputs. This is a
       major benefit. Tests can be specified to lead the ICD software through complex, tightly controlled
       simulations. A second benefit comes from the fact that these tests can be accurately reproduced
       on demand. Software validation done with the Neutrino EMT+ is highly automated. Once a test
       has been developed, it can be used over and over to validate changes in the embedded code.
       Finally, the Neutrino EMT+ collects all of its inputs into a data base compatible format. This will
       help us automate the evaluation of test results in addition to automating the actual test procedure.

       The need for this internal St Jude Medical product is based on our desire to deliver the highest
       quality embedded software possible for our ICD products. The Neutrino EMT+ will not be able to
       automate all aspects of software validation, but it will be invaluable for the portion of testing that
       can be automated. The Neutrino EMT+ will provide more exhaustive and reproducible testing
       than equivalent semi-automated or manual approaches.

2.2.   Product Functions
       As stated in the Product Perspective, the primary purpose of the Neutrino EMT+ is to exercise the
       ICD embedded software. To do so, the Neutrino EMT+ shall run the tests and save the results.
       The Neutrino EMT+ shall also provide a user interface from which a knowledgeable user can
       define, control, and evaluate results of the testing. Where real time interdependencies exist
       between inputs and/or outputs, the Neutrino EMT+ shall synchronize the related signals as
       defined by the test.

       Figure 1 provides a block diagram of the major components presented here. We cover each of
       these components as a "functional interface" in section three of the specification. The dotted lines
       in the graphic represent internal Neutrino EMT+ communication, with the Test Controller as the
       "master" interface directing activities of the other functional interfaces. The major changes from
       the Scout EMT are the quad chamber (right and left Atrial/ right and left Ventricular), real-time
       operating extensions to Windows NT, threshold measurement of the pacing evoked response,
       improved error logging, display of realtime EGMS, storage of realtime and stored EGMs, and
       hardware changes to accommodate Neutrino ICD hardware changes..

       Note that the Chart Recorder and Logic Analyzer can be indirectly controlled to some degree by
       the Digital Outputs interface.




       PN# TBD           St. Jude Medical CRMD Confidential         October 16, 2011         Page 4
                  St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.



                                                             Test
                                                            Controller




                                                       Engineering
                             Digital Data
                               Player                  Programmer
                                                                         Pacing
                             Atrial Vent.
                                                                      Atrial Vent.
                     Heart
                     Simulator
                                                                                     HV Shock
                     Atrial Vent.
                                                                                        Digital
                 Chart Rec.             Chart                ICD                      Act. Sensor
                 Comm.                 Recorder             under
                                                             test
                                                                                BAR
                                                                                               BAR
                                                                                               Comm.
                     Digital
                    Outputs
                                                                                                    Clip File
             Logic An.                                                                              Player
                                      Logic Analyzer                             Digital
             Comm.
                                                                                 Inputs


                                    Figure 1 - Component block diagram
2.3.   User Characteristics
       Users of the Neutrino EMT+ will be experienced engineering and/or test personnel. The Neutrino
       EMT+ is intended only to be an engineering development and verification tool. Its use in the field
       is specifically precluded.

2.4. General Constraints
2.4.1. Standards Compliance
       No standards-related limitations have been identified.
2.4.2. Hardware Limitations
        1.   The Neutrino EMT+ only needs to work with the Scout and Neutrino defibrillator breadboard
             systems.

        2.   The Pacing and High Voltage Shock interfaces monitor analog inputs that have digital
             equivalents as inputs to the Digital Inputs interface. The analog monitoring interfaces are
             only required to measure leading edge pulse amplitudes, at a time closely corresponding to
             the rising edge of the equivalent digital signal. There is no provision to save trailing edge

       PN# TBD           St. Jude Medical CRMD Confidential       October 16, 2011         Page 5
                 St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


             voltage measurements or to recognize happenings based directly on the analog data. All
             timing measurements and happenings will be based on the digital signals.
2.4.3. Software Limitations
        1.   The Neutrino EMT+ only needs to respond to detectable events, as specified by all of the
             input data described in Section 3. Any test that requires inputs or outputs not specified
             here is beyond the scope of the Neutrino EMT+. For example, a test of the DC-DC power
             converter efficiency would not use the Neutrino EMT+.

        2.   These Neutrino EMT+ requirements dictate a master-slave implementation where the other
             functional interfaces are "dumb slaves" to the Test Controller in real time. A design that
             allows the functional interfaces to interact as peers during the test may yield better
             performance, although it will also be more complex. For example, a test that requires
             feedback from the Digital Inputs interface before requesting a block mode interrogation
             through the Engineering Programmer interface shall rely on the Test Controller interface to
             synchronize the two steps. Digital Inputs notifies the Test Controller, then the Test
             Controller commands the Engineering Programmer, It would be more efficient to have
             Digital Inputs notify the Engineering Programmer directly, but such direct "peer-to-peer"
             functionality is not required at this time.

        3.   Multiple test scripts/programs cannot be run concurrently because system behavior would
             be unpredictable.

        4.   shall For any response time requirements that could be affected by file I/O overhead, the
             stated limit may not be met when the associated hard disk is severely fragmented or the
             associated directory on that disk already contains thousands of files.

        5.   The user is constrained to use the same compiler for generation of C++ executables as is
             used to generate the Neutrino EMT+ C++ API. (Compiler choice is an implementation
             decision.)

2.5.   Assumptions and Dependencies
        1.   The Neutrino EMT+ requirements depend on the Neutrino defibrillator requirements. They
             may not be appropriate for future generations of ICD development. We assume that the
             Engineering Mode Tester requirements will evolve along with the Neutrino system product
             requirements.

       Many additional dependencies are stated in section three as subsections within the functional
       areas that they address.

2.6.   Goals
        1.   Neutrino EMT+ performance shall be as good as or better than Scout + performance.

        2.   The Neutrino EMT shall be able to ignore unused subsets of inputs and outputs. This
             requirement extends to mean that single, dual and quad chamber operation shall all be
             supported.

        3.   The Neutrino EMT+ shall be able to recognize and time tag spurious input events as well as
             expected input events. A test may fail because an expected event did not appear or
             because the event appeared at the wrong time; it could also fail because extra unexpected
             events were recorded. Extra unexpected events can be detected by enabling extra logging
             and later examination of the log files.




       PN# TBD          St. Jude Medical CRMD Confidential       October 16, 2011        Page 6
          St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


 4.   Where Neutrino EMT+ functional interface requirements overlap substantially with the
      requirements for stand-alone development tools, the designs shall attempt to address those
      common requirements with a single implementation.

 5.   Conversely, Neutrino EMT+ functional interfaces shall, where possible and reasonable, be
      available for use in a standalone mode. The Cadet Engineering Programmer performed
      this purpose well. Another candidate for standalone operation is the Heart Simulator (HS)
      functional interface.

 6.   shall Interoperation with the BAR is desirable. The simple approach is for the Neutrino
      EMT+ to provide a command to query the status of the BAR, in particular to find out if the
      BAR is ready to acquire data. Also, Digital Output lines can be used to clear and start data
      acquisition.




PN# TBD          St. Jude Medical CRMD Confidential       October 16, 2011         Page 7
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3. Functional Requirements
3.1.       Overview
           The specific requirements are grouped by functional interface. Information on the inputs to the
           Neutrino EMT+, outputs from the Neutrino EMT+, data to be gathered, and interdependencies
           between functional interfaces is given in the following subsections. The Neutrino EMT+ shall be
           able to generate the outputs, measure the inputs, coordinate interactions, and collect the resulting
           data in an organized fashion.

           Requirements that are the same for all functional interfaces are presented together in the
           Common Functional Requirements subsection. Requirements unique to each functional interface
           follow, with a separate subsection for each interface.

3.2. Common Requirements
3.2.1. Coordination
           Because all functional interfaces hold knowledge about the ICD state, they are all affected by
           coordination requirements. In this subsection, only system level requirements that are common to
           all interfaces are covered.

3.2.1.1.        Simultaneous Operations
           In general, this FRS describes a "single threaded" control system.

           Simultaneous control is needed in some cases. For example, the Neutrino EMT+ shall be able to
           generate pulses from the Heart Simulator while monitoring a Digital Input interface line for a pace
           pulse indication. The Neutrino EMT+ shall be able to perform telemetry while monitoring the
           microprocessor bus.

           Errors detected by a functional interface at run time shall be reported to the Test Controller.
           Specific errors to be reported are defined in the individual interface requirements.

           By issuing the proper commands in sequence, the Test Controller can start up simultaneous
           operations on multiple interfaces.

           Support for simultaneous operations introduces the need for asynchronous coordination of
           functional interfaces. Asynchronous coordination requirements are expressed in this FRS in the
           form of "happenings." The next subsection explains happenings in more detail. Additional
           specifics are included later in the Commands subsections for the affected functional interfaces.

           Each functional interface that can recognize happenings shall provide commands for the
           specification of happenings and a corresponding operating mode to monitor for happenings.
           Specific requirements for these happenings are found in the individual interface requirements.

           The Neutrino EMT+ addresses requirements for simultaneous operations by defining "operating
           modes" for the functional interfaces. An operating mode is entered via a command that specifies
           the work to be performed.

           Support for operating modes introduces the potential for a special class of run time errors
           because an interface will not always be in an "idle state" when a command is received. For
           example, asking the Heart Simulator interface to prepare for a new test while it's in the middle of
           generating a requested pulse sequence would be an error. The Error Handling subsection
           explains errors related to operating modes in greater detail. Additional specifics are included later
           in the Commands subsections for the affected functional interfaces.



       PN# TBD               St. Jude Medical CRMD Confidential        October 16, 2011         Page 8
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           COM_03:
           For commands that do not request an operating mode, a functional interface shall perform the
           requested work before responding to the Test Controller with a success or failure indication.

           COM_04:
           For commands that request an operating mode, however, the functional interface shall
           acknowledge that it will service the request BEFORE performing the requested work The
           response indicates whether or not the operating mode was started successfully.

3.2.1.2.        Asynchronous Coordination
           The Neutrino EMT+ controls its outputs in a coordinated fashion and collects the resulting data
           from its inputs. The concept of a "happening" is central to this need for coordination. A
           happening corresponds to a set of conditions being met at a certain point in time These
           conditions are of interest to the test being run.

           A test may use a happening simply to demonstrate that the corresponding state was reached, to
           show that the state was reached at the proper time, or to lead the ICD to another state as part of a
           higher level simulation. Happenings may also be used to show, by their absence in the resulting
           data, that a state was NOT reached during the test.

           Every happening has three parts: specification, recognition, and response. Let's look at the use of
           happenings to measure a sense-to-pace interval as a simple example of this concept. The
           specification of the happening would be directed to the Digital Inputs functional interface in the
           form of a command:
               •     Whenever the VPACE signal transitions from low to high, notify the Test Controller
                     interface that happening #1 (a unique identifier) has occurred.

           By accepting this specification, the Digital Inputs interface agrees to monitor VPACE during the
           test while continuing to serve other commands, and to notify the Test Controller interface
           whenever the ICD delivers a pace pulse (VPACE goes 0 1).

           The response to a happening will always be performed as a sequence of commands run by the
           Test Controller interface once notification arrives. For this simple interval test example the
           response might be:
               •     wait 145 ms
               •     generate a 33 ms haversine pulse with a 10 mV peak
               •     wait for the next notification of happening #1
           The first recognition of the happening specified for the Digital Inputs interface would cause the
           Heart Simulator interface to respond by generating a pulse outside the pace refractory period.
           The Test Controller interface would then wait for a second notification of the same happening and
           end the test. After the test finished, we could calculate a sense-to-pace interval by subtracting the
           time that the pulse was generated from the time of the second happening.

           Requirements that test happening functionality are enumerated within the command requirements
           for Specify <FI> Happening, Specify Happening Repeat Count, Wait For Happening, Start
           Happening, Check For Happening, and Stop Happening. (“<FI>” is different for each functional
           interface that defines happenings.)
3.2.2. Error Handling
           In general, the Neutrino EMT+ shall be able to detect and handle a wide range of errors. This is
           an important requirement because the system will be used to test life-critical software embedded



       PN# TBD               St. Jude Medical CRMD Confidential        October 16, 2011         Page 9
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           in the ICD.   This section describes the error types that shall be handled by each functional
           interface.

3.2.2.1.        Data Range Errors
           Individual data range requirements are specified in the Commands subsection for each functional
           interface.

3.2.2.2.        Run Time Errors
           COM_09: When a test is aborted, data already collected prior to the failure shall be preserved to
                   support diagnosis of the failure.
           COM_10: The partial data sets resulting from failed runs shall have a log file entry indicating that
                   the test was aborted so that the user can distinguish between the results of successful
                   and aborted tests.

3.2.2.2.1.         Hardware Errors
           Once a test is "confirmed" to be free of syntax, data type, and data range errors, the Test
           Controller interface will start the test. During this process, a functional interface may fail to
           perform a requested command because of a hardware problem. Few hardware errors are
           specified in this FRS because they will depend on the specific implementation of each functional
           interface.

           COM_11: Each functional interface shall detect and report detectable hardware errors within 10
                   seconds.
           For example, a 30 minute RAM test is not an acceptable diagnostic to perform at this time. A
           more appropriate test might be a register write/read.
3.2.2.2.2.         Operating Errors
           General operating error requirements are specified in this section. More specifics are contained
           in the requirements for each individual functional interface.

           COM_15: For interfaces that use dynamic memory allocation, the failure of an attempt to allocate
                   memory shall be considered an operating error. Any error shall cause an immediate
                   indication to be returned to the Test Controller.

3.2.2.2.3.         Timeout Errors
           A maximum response time is specified in this FRS for each command. The functional interface
           designs are discouraged from using intentional timeouts as error indications because they are by
           nature non-specific. In any case, timeout errors are still preferred over the complete failure to
           detect an error.
3.2.3. Inputs
           Inputs to the Neutrino EMT+ will come from the outputs of the ICD under test and from user
           commands. Details of ICD generated inputs are specified in the following subsections under the
           Functional Requirements By Interface section, organized by functional interface. Details of the
           user interface are in the External Interfaces section.
3.2.4. Outputs
           Outputs from the Neutrino EMT+ are sent to the inputs of the ICD. Results of tests and
           responses to user commands are also Neutrino EMT+ outputs, sent to a video display or to data
           files. Monitoring of EGMs and other signals shall be provided. Hard copy of these monitored
           signals shall also be provided.


       PN# TBD               St. Jude Medical CRMD Confidential        October 16, 2011        Page 10
                       St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.2.5. Commands
           Each functional interface shall support a set of commands unique to its capabilities. These are
           defined in the Functional Requirements By Interface section. Here we present the environment
           for running commands and a set of common commands to be supported by all interfaces.

           A command represents a unit of work to be performed by a functional interface. That work might
           be to initialize a local data structure, to change the state of an output, to respond to the state of an
           input, etc. Each command is given a name that conveys its role within the system and a
           description that specifies, at a high level, the work to be done. Data required to perform a
           command are enumerated as parameters to support the description.

           Interfaces are only expected to service commands sequentially. Once a command begins to run
           it shall go to completion without being interrupted.

           Commands are translated into OOA events by the Test Controller. Internal to the system, events
           are the actual carriers of information.

           To improve Test Controller responsiveness, interface activities that take significant amounts of
           time are specified as operating modes, with one command to enter the mode and another to exit.

           COM_17: When in an operating mode, the interface shall be able to support the specified
                   ongoing operation and simultaneously accept command input.
3.2.5.1.          Required Commands
           The following commands are common to and shall be supported by all functional interfaces.
3.2.5.1.1.          Prepare For Test
           The Prepare For Test command notifies the interface that a new test is about to start.

           COM_19: Upon receipt of the Prepare For Test command, each functional interface shall
                   prepare to provide its full range of services specified in this FRS, including initialization
                   of system resources such as dynamic heap space, the file system, I/O cards, etc.
           COM_21: The Prepare For Test command shall specify the test name, and a unique file name
                   assigned to the interface for storage of collected data or a reserved name indicating
                   that data should not be collected. The file name is derived from a user-specified
                   name. The following parameters are required.
             1.    Test identifier: Test name and unique identifier for collected data.

             2.    Unique file name: A file name generated by the Test Controller for use by this functional
                   interface. The file name includes a full path specified by the Test Controller.

           This unique file should not be confused with any additional files that may be generated by
           individual functional interfaces. This file is the primary log of actions executed by a functional
           interface.

           COM_23: Each interface shall perform the hardware diagnostics required by the functional
                   interface in response to the Prepare For Test command.
           This requirement is included to decrease the probability of hardware errors during a test. Specific
           diagnostic tests to be chosen are implementation dependent.




       PN# TBD                 St. Jude Medical CRMD Confidential        October 16, 2011         Page 11
                   St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


        COM_25: If any problems are detected by the hardware diagnostics run during handling of the
                Prepare For Test command, an error indication shall be returned to the Test
                Controller.
        COM_27: Every functional interface shall be able to respond to the Prepare For Test command
                when the functional interface is idle.
        COM_29: Every functional interface shall return a success or failure indication to the Prepare For
                Test command within 60 seconds.
        COM_31: An operating error indication shall be returned if the specified "unique" file name
                already exists.
        COM_33: An operating error indication shall be returned if the specified "unique" file cannot be
                opened.
        COM_35: An operating error indication shall be returned if the specified "unique" file cannot be
                written.


3.2.5.1.2.       Finish Test
        The Finish Test command notifies a functional interface that the current test is finished.

        COM_43: Before responding to the Finish Test command, the interface shall "flush" all collected
                data to the assigned file and close the file.
        COM_45: The Finish Test command is always accepted after the interface has completed the
                Prepare For Test command.
        An operating error indication will not be returned if the Finish Test command is used without the
        Prepare for Test command, presuming that no other constraints and restrictions have been
        violated.

        COM_46: Each functional interface shall terminate any currently running operations, including
                operating modes, upon receipt of the Finish Test command.
        COM_47: Every functional interface shall return a success or fail indication to the Test Controller
                within 60 seconds of receiving the Finish Test command.

3.2.5.1.3.       Abort Test
        The Abort Test command notifies a functional interface that the current test is to be abandoned,
        either due to a user-requested abort or due to a detected run time error. No parameters are
        required.

        COM_49: Before responding to an Abort Test command, the interface shall "flush" all collected
                data to the assigned file and close the file in preparation for error diagnosis.
        (The functional interface may return an error if the file operation fails, but is not required to do so
        because the system is already in an error state.)




       PN# TBD             St. Jude Medical CRMD Confidential        October 16, 2011         Page 12
                       St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           COM_53: Every functional interface shall be able to respond to the Abort Test command at any
                   time. Because the Abort Test command is an intentional interrupt, operating errors
                   shall NOT be returned, even if the interface is in an operating mode at the time of
                   receipt.
           COM_55: Every functional interface shall go to an idle state, and return a success or failure
                   indication to the Abort Test command within 60 seconds.
3.2.5.2.          Happening Commands
           Functional interfaces which have the ability to detect happenings shall support a few additional
           commands to fulfill their responsibilities for the coordination of happenings. The actual
           specification of happening conditions is interface specific and is discussed within the specific
           functional interface section. The remainder of the happening commands are discussed below.
3.2.5.2.1.          Specify Happening Repeat Count
           COM_57: The Specify Happening Repeat Count command informs a functional interface that a
                   happening is satisfied only after the specified number of repetitions have been
                   detected. Three parameters are required.
             1.    interface ID: the functional interface which has defined the happening.

             2.    happening ID: This is the identifier used for notification that is defined as part of the
                   happening specification.

             3.    repeat count: Specifies how many times the conditions shall be met before this happening
                   is recognized. Valid values shall be between 1 and 2,147,483,647.

           Use of the Specify Happening Repeat Count command is optional.

           COM_58: An error indication shall be returned to the Test Controller when out of range values
                   are given for the Specify Happening Repeat Count command.
           COM_59: Functional interfaces shall support a single repeat count per happening ID.
           COM_61: Functional interfaces shall initialize the repeat count to 1 for all happening ID’s within
                   the interface.
           COM_63: A changed repeat count shall supersede the previous value.
           COM_65: If the Specify Happening Repeat Count command is issued to a functional interface
                   after a Start Happening command has been issued to this same functional interface
                   without a corresponding Stop Happening command, an error should be reported.
           COM_67: After any happening is satisfied with the specified number of repetitions, the repeat
                   count shall stay the same for subsequent happening commands.
           COM_69: A success or failure indication shall be returned within 2 ms from the Specify
                   Happening Repeat Count command.

3.2.5.2.2.          Wait For Happening
           COM_71: The Wait For Happening command forces the interface to wait for notification of a
                   happening. Three parameters are required.
             1.    interface ID: the functional interface which has defined the happening(s).

             2.    happening ID: This is the identifier used for notification that is defined as part of the
                   happening specification. For functional interfaces that do not support multiple simultaneous
                   happening specifications, this parameter is still required and shall be included to preserve



       PN# TBD                St. Jude Medical CRMD Confidential        October 16, 2011        Page 13
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


                  consistency. For functional interfaces that support multiple happening specifications, this
                  parameter shall support a list of IDs.

             3.   time limit: Maximum number of milliseconds to wait before returning a time-out indication.
                  Valid values shall be between 1 and 2,147,483,647 ms.

        COM_72: An error indication shall be returned to the Test Controller when out of range values
                are given for the Wait for Happening command.
        COM_73: If a happening has been satisfied, the Wait For Happening command shall indicate the
                satisfied happening ID and the system time when the happening was satisfied.
        COM_75: If notification is not received by the Wait For Happening command within the specified
                limit, a time-out failure indication shall be returned to the Test Controller.
        COM_77: When a list of happening IDs is provided, the happening shall be satisfied when the
                first arriving notification that matches an ID from the list is received.
        COM_79: If Wait For Happening is requested while an interface is in a non-blocking mode, the
                Wait For Happening request shall cause the interface to enter a blocking mode. The
                interface shall wait for the happening(s) specified by the Wait For Happening request.
        (The converse situation is not possible because an active blocking wait has complete control of
        the system until it is satisfied, is aborted by the user, or times out.)
3.2.5.2.3.         Start Happening
        COM_81: The Start Happening command is a precursor to Check For Happening. Start
                Happening tells the functional interface to enable polling for happenings in a non-
                blocking mode. Two parameters are required.
             1.   interface ID: the functional interface which has defined the happening(s).

             2.   happening ID: This is the identifier used for notification that is defined as part of the
                  happening specification. For functional interfaces that do not support multiple simultaneous
                  happening specifications, this parameter is still required and shall be included to preserve
                  consistency. For functional interfaces that support multiple happening specifications, this
                  parameter shall support a list of IDs.

        The number of happenings supported by a functional interface is interface dependent.

        COM_82: An error indication shall be returned to the Test Controller when out of range values
                are given for the Start Happening command.
         COM_83: A success or failure indication shall be returned within 2 ms from the Start Happening
                 command.
3.2.5.2.4.    Check For Happening
        COM_85: The Check For Happening command is similar to Wait For Happening, but it is non-
                blocking. One parameter is required.
             1.   interface ID: the functional interface which has defined the happening(s).




       PN# TBD               St. Jude Medical CRMD Confidential        October 16, 2011        Page 14
                       St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           COM_86: An error indication shall be returned to the Test Controller when out of range values
                   are given for the Check for Happening command.
           COM_87: If any of the happenings specified by the Start Happening command has occurred,
                   then the detected happening ID and system time of detection shall be returned to the
                   Test Controller.
           COM_89: If none of the happenings specified by the Start Happening command has occurred,
                   then a return value that indicates the same shall be returned to the Test Controller.
           COM_91: If Start Happening has not been performed prior to the Check For Happening
                   command, an error indication shall be returned.
         COM_95: A success or failure indication shall be returned within 2 ms from the Check For
                 Happening command.
3.2.5.2.5.    Stop Happening
           COM_97: he Stop Happening command ends the non-blocking happening operating mode.
                   Stop Happening tells the functional interface to stop polling for happenings in a non-
                   blocking mode. One parameter is required.
             1.    interface ID: the functional interface which has defined the happenings.

           COM_99: If this functional interface is not in the non-blocking happening operation mode when
                   the Stop Happening command is run, a success indication shall be returned to the
                   Test Controller by the Stop Happening command. No other action shall be performed.
           COM_101: A success or failure indication shall be returned within 2 ms from the Stop Happening
                    command.
3.2.5.3.          Output Control Commands

3.2.5.3.1.          Stop Current Output

           COM_121: The Stop Current Output command terminates the current output and operating mode
                    unconditionally. The affected output shall be returned to a digital zero value. One
                    parameter is required.
             1. interface ID: the affected functional interface for which the stop output applies.

           COM_125: The Stop Current Output command shall return a success or failure indication.
           Specific performance numbers are provided in the sections specific to functional interfaces that
           support output control commands.

           COM_127: It shall not be considered an error to service the Stop Current Output command when
                    no output is in effect for the designated functional interface. A successful indication
                    shall be returned without any other action taking place.
           3.2.5.3.1.1. Stop All Output
           COM_131: The Stop All Output command functions shall clear any staged operation from the
                    buffer, forcing the affected functional interface to an idle state. One parameter is
                    required.
             1. interface ID: the affected functional interface for which the stop output applies.

           COM_133: The Stop All Output command shall return a success or failure indication.
           Specific performance numbers are provided in the sections specific to functional interfaces that
           support output control commands.



       PN# TBD                St. Jude Medical CRMD Confidential        October 16, 2011        Page 15
                    St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


        COM_135: It shall not be considered an error to service the Stop All Output command when no
                operating mode is in effect for the affected interface. A successful indication shall be
                returned without any other action taking place.
shall 3.2.5.4. Wait For Idle
        COM_137: The Wait For Idle command shall complete once the affected interface leaves its
                 operating mode because all staged requests have been completed. One parameter is
                 required.
          1. interface ID: the affected functional interface for which the stop output applies.

        COM_139: It shall not be considered an error to service the Wait For Idle command when no
                 operating mode is in effect. A successful indication shall be returned without any other
                 action taking place.
        COM_141: If a failure is returned for the Wait for Idle command, this failure shall be returned
                 within 10 ms.
3.2.6. Data
        Data from each individual test shall be saved. All collected data shall include system time tags to
        allow for correlation of results and for validation of system performance.

        COM_103: Each test executed by a functional interface shall save the following common
                   information.
        field name              type            description
        associated test         string          unique ID provided by the Prepare For Test
                                                command.
        date and time           string          Identifies when the test was started, using a
                                                time of day clock independent of the system
                                                time base. The saved date shall include all
                                                four digits of the year. The time shall include
                                                hour, minute, and second.
        data source             string          Identifies the data stream.
        COM_105: Each data item saved by a test shall have the following common information.
          1.   system time tag: Identifies when the data was collected within the test. This time tag
               comes from the system time base (which provides 1ms resolution), relative to time = 0ms
               at the start of the test.
3.2.7. Performance and Timing
        The overall performance requirements are addressed in section 4.
        shall COM_111: The Neutrino EMT+ shall be able to respond to a happening within 5 ms of
                  detection of the happening on any functional interface. The response to a happening
                  is dictated by the Test Controller interface, based directly on the user's test
                  specification.
3.2.8. Constraints
        Tests that require happenings which cannot be recognized by a single functional interface as
        specified here are not within the Neutrino EMT+ scope. Some of these tests might be supported
        by using sequences of happenings, but only if the combined sequential response time is sufficient
        for the test.

        The maximum number of happenings allowed per functional interface is 16. The minimum is one.

        After an error has been detected, all commands attempted except Abort Test shall result in an
        error. The error shall indicate that an error has previously been detected.


       PN# TBD                 St. Jude Medical CRMD Confidential    October 16, 2011        Page 16
                St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.2.9. Dependencies
     Specific dependencies are described for each functional interface within the sections specific to
     each functional interface. In general, the functional interfaces can depend on each other in many
     ways, based on the design of each test specification. Such "user-defined dependencies" all rely
     on the Test Controller interface's ability to supervise activities during the test, but they also rely on
     each functional interface to respond quickly at the command level. See the Constraints section
     for some limitations that are imposed on user-defined dependencies.




     PN# TBD            St. Jude Medical CRMD Confidential          October 16, 2011         Page 17
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.




3.3.       Neutrino Engineering Programmer
           The Engineering Programmer (EP) interface provides the primary data pipe between the Neutrino
           EMT+ and the ICD. The Neutrino EMT+ shall be able to send commands and respond to the ICD
           over the telemetry link. Details of the commands that control the EP interface are found in the
           “Engineering Programmer API Description and Procedure Semantics” section of the Neutrino
           Engineering Mode Tester Plus – User’s Guide.

           EP_03:         The EP interface shall perform the actions described in the “Engineering
                      Programmer API Description and Procedure Semantics” section of the Neutrino
                      Engineering Mode Tester Plus – User’s Guide [11].
3.4.       Pacing
           The ICD delivers brady and antitachycardia pacing to the heart. The Scout EMT Pacing functional
           interface measures the analog values of these pace inputs.

           PAC_03:    The Scout EMT must support monitoring of leading edge voltages for atrial and
                      ventricular pacing channels.
3.4.1. Inputs
           Inputs to the Pacing interface are real time waveforms generated by the ICD. These waveforms
           are generally composed of one or more pacing pulses.

           PAC_05:    The Scout EMT must provide a fixed or manually adjustable impedance load to both
                      the atrial and ventricular channels.
           The adjustable impedance load was little used in the Cadet EMT. A fixed load, or external resistor
           connector, should be adequate.
3.4.2. Outputs
           There are no outputs from the Pacing interface.
3.4.3. Commands
           The Pacing interface must support commands in addition to those specified for all functional
           interfaces in the common requirements section.

3.4.3.1.       Start Pacing Peak Detection
           The Start Pacing Peak Detection command enables peak detection as an operating mode.




       PN# TBD               St. Jude Medical CRMD Confidential      October 16, 2011        Page 18
                     St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           PAC_07:   Once pacing peak detection has been started, the Pacing interface must monitor the
                     two pacing channels for any peaks.
           PAC_09:   Once pacing peak detection has been started, the receipt of any command other than
                     Stop Pacing Peak Detection, Finish Test, or Abort Test shall cause an operating error
                     indication to be returned after aborting from the operating mode.
           PAC_11:   A success or failure indication must be returned within 10 ms from the Start Pacing
                     Peak Detection command.
3.4.3.2.       Stop Pacing Peak Detection
           PAC_13:   The Stop Pacing Peak Detection command is the complement to Start Pacing Peak
                     Detection.
           PAC_15:   The Stop Pacing Peak Detection command shall force the current peak detection
                     operating mode to terminate immediately.
           PAC_17:   If the Stop Pacing Peak Detection command is requested while no pacing peak
                     detection is in progress, the Pacing interface shall perform no action except to return a
                     success indication.
           PAC_19:   A success or failure indication must be returned within 10 ms from the Stop Pacing
                     Peak Detection command.
3.4.4. Data
           PAC_21: The Pacing interface must save the following data for every detected peak.
           field name            type            description
           system timetag        unsigned long Time of peak detection.
           operation             enumerated      PACE_PEAK
           chamber               enumerated      Chamber were the pace peak was detected:
                                                 ATRIUM or VENTRICLE
           peak voltage          float           The measured leading edge voltage.


3.4.5. Performance and Timing
           PAC_23:   Pacing peak voltages must be measured over a range of 0.0 V to +10.0 V with 250 mV
                     resolution.
           The main use of the Pacing functional interface is to allow for binning of outputs.          These
           tolerances should not be any more stringent than needed to provide this capability.

           PAC_25:   The pacing peak time tag must be within 1 ms of the actual detection time.
           (The Digital Inputs interface provides high resolution timing data; see the related general
           constraint in section 2.4.)

           PAC_27:   The pacing peak measurement must be accurate to within 250 mV.
           PAC_29:   The Pacing functional interface must be able to meet all requirements for pulses down
                     to 100 s wide.
           PAC_31:   The Pacing functional interface must be able to meet all requirements for pace pulse
                     leading edge separation as short as 10 ms.
3.4.6. Constraints
           The analog measurements made by the Pacing interface are primarily intended to support gross
           differentiation and possibly binning of pacing signals. Higher precision analog measurements
           should be made with other instruments.



       PN# TBD              St. Jude Medical CRMD Confidential        October 16, 2011        Page 19
                St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.4.7. Dependencies
     Pulse width measurements will be made using the digital pacing signal that is routed to the Digital
     Inputs interface. Only the analog pulse height measurement requirement is allocated directly to
     the Pacing interface. This dependency is acceptable for the Scout EMT because only the
     breadboard configuration is supported, and we assume that the width of the digital pulse agrees
     closely with that of the analog signal.




     PN# TBD           St. Jude Medical CRMD Confidential       October 16, 2011        Page 20
                  St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.




3.5.   Heart Simulator
       Sensing leads are used by the ICD to monitor the electrical signals from the heart. The Neutrino
       Heart Simulator (HS) interface outputs signals to two sensing channels (atrial and ventricular).
       The Heart Simulator also monitors two channels (atrial and ventricular) of inputs from the ICD
       pacing outputs, as well as the atrial and ventricular inputs from the ICD HV output. Details of the
       commands that control the HS interface are found in the Heart Simulator Functional
       Requirements Specification.

       HS_03:     The HS interface shall perform the actions described in the Neutrino HS FRS [4].
3.6.   Direct Digital Player
       The Direct Digital Player (DDP) functions as a digital replacement for the Heart Simulator. Its
       intended use is to support precise testing of the Neutrino morphology hardware and software by
       bypassing the front end electronics and submitting real time digital data directly to the device’s
       morphology and sense channels. Sense channel data is useful to precisely determine when the
       peak is sensed by the device.

       DDP_05:    The Neutrino EMT+ shall be able to start, change, or terminate Direct Digital Player
                  output in response to any therapy input, telemetry message, or other time tagged
                  event. The flexibility to meet this requirement is provided by this interface in
                  coordination with the Test Controller interface.
3.6.1. Inputs
       There are no inputs into the DDP interface.
3.6.2. Outputs
       DDP_11:    The DDP shall output digital data to the Neutrino ventricular morphology channel, as
                  defined in the data file.
       DDP_13:    The DDP shall output digital data to the Neutrino ventricular sense (VSENSE) channel,
                  as defined in the data file.
       DDP_15:    The DDP shall output digital data to the Neutrino atrial sense (ASENSE) channel, as
                  defined in the data file.
       DDP_17:    The DDP shall provide a fixed output mode.
       This mode allows a user to conveniently simulate single point waveforms of a specified peak
       without having to generate the corresponding set of waveform data files.

       DDP_19:    The Neutrino EMT+ shall produce correctly timed intervals with waveforms of
                  predictable peaks. An interval is defined here as a "pre-pulse delay" period followed
                  by an arbitrary digitized EGM waveform read from a disk file. The waveform’s duration
                  is calculated by multiplying the pulse width by the number of samples in the waveform
                  file. Pulse width is defined as 2 milliseconds multiplied by the per-sample repeat
                  count. The peak is the sample that has the maximum rectified value compared with all
                  other samples in the waveform.
3.6.3. Commands
       The Direct Digital Player interface must support commands in addition to those specified for all
       functional interfaces in the common requirements section.




       PN# TBD           St. Jude Medical CRMD Confidential       October 16, 2011        Page 21
                       St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.6.3.1.       Stage Interval/Amplitude Output
           DDP_21:   The Stage Interval/Amplitude Output command tells the interface to prepare for
                     Interval/Amplitude Mode operation, based on the following parameters.
               1. pre-waveform delay: Specifies a delay in milliseconds to wait in each interval before
                  starting to play the waveform.
                  Valid range is between 10 and 9999999 ms.
               2. sample repeat count: Number of times to repeat each data sample.
                  Valid range is between 1 and 5.

                   Repeating the sample is useful when the original data is sampled at a slower rate. The
                   following table shows the possibilities:
                   SAMPLE RATE             REPEAT COUNT
                   500 Hz                  1
                   250 Hz                  2
                   167 Hz                  3
                   125 Hz                  4
                   100 Hz                  5
               3. waveform identifier: Valid range is a number from 0 to 99999998. The waveform
                  identifier value is converted into a string which will be used as a waveform’s base file
                  name along with the extension “.TXT” in a pre-defined waveform directory.
               4. number of intervals: Specifies how many times to repeat the interval. Valid range is
                  between 0 and 2,147,483,647.
               5. startup mode: Dictates the method of operating synchronization. Choices are:
                  1.     now: change immediately from the current mode
                  2.     next interval: change at the end of the current interval
                  3.     wait: change at the end of the last interval, when the current mode finishes

           DDP_22:     DDP output waveforms shall be queued in First-In First-Out (FIFO) order.
           DDP_23:     DDP output shall be driven from a data file, using the following format.
           Each line of the data file corresponds to the data value to be output for the next 2 ms. The
           individual entries shall be separated by commas. The VSENSE and ASENSE entries are
           optional. The entries are:
               1. Ventricular Morphology (Morph) Data: Sample value to output to morphology channel.
                  Range is -127 to +127.
               2. VSENSE Data: Sample value to output to VSENSE channel. Range is -127 to +127.
               3. ASENSE Data: Sample value to output to ASENSE channel. Range is -127 to +127.




       PN# TBD               St. Jude Medical CRMD Confidential         October 16, 2011          Page 22
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           DDP_24:    If the commas between DDP data entries are missing, an error shall be reported. It is
                      acceptable for the data entries themselves to be missing.
           DDP_25:    To allow flexibility, all three DDP data entries (Morph, VSENSE, ASENSE) are
                      optional. A 0 sample value shall be output to the channel whose entry is missing.
           DDP_28:    Before starting each waveform defined by the Stage Interval/Amplitude Output
                      command, the DDP shall check for a handshake error. An error indication shall be
                      returned if a handshake error has occurred.
           DDP_29:    For any startup mode specified by the Stage Interval/Amplitude Output command, the
                      DDP interface shall switch to this new interval definition within 1 ms of terminating the
                      previous interval definition.
           DDP_30:    If the number of intervals specified by the Stage Interval/Amplitude Output command
                      is 0, the waveform shall repeat until another command (Stop Current Output or Stop
                      All Output) stops the output or until the interface is reset by a Finish Test or an Abort
                      Test command.
           DDP_31:    DDP output waveform files shall be able to contain from 1 to 320000 newline delimited
                      data points.
           At 2 ms per data point, the maximum output time of one output waveform is 640 seconds.

           DDP_35:    The user shall be able to load (from waveform files) up to 100 arbitrary waveforms per
                      test.
           DDP_37:    Up to 150 stage buffers shall be queueable via startup mode 3.
           Note that multiple stage buffers may refer to a single arbitrary waveform. Only one stage buffer is
           required via startup mode 2.

           DDP_39:    While the stage buffer already holds an operation waiting via startup mode 2, the
                      Stage Interval/Amplitude Output command shall return an operating error indication for
                      subsequent mode 2 requests.
           DDP_41:    The previous staged operation shall always take precedence.
           DDP_43:    The Stage Interval/Amplitude Output command shall return a success or failure
                      indication within 2 ms.
3.6.3.2.       Stage Spike Output
           DDP_45:   The Stage Spike Output command tells the interface to generate output of a specified
                     amplitude, based on the following parameters.
               1. pre-waveform delay: Specifies a delay in milliseconds to wait in each interval before
                  starting the output waveform.
                  Valid range is between 10 and 9999999 ms.
               2. spike height: Specifies the digital amplitude of the pulse spike.
                  Valid range is -127 to +127.
               3. number of intervals: Specifies how many times to repeat the interval.
                  Valid range is between 0 and 2,147,483,647.
               4. startup mode: Dictates the method of operating synchronization. Choices are:
                     1.   now: change immediately from the current mode
                     2.   next interval: change at the end of the current interval
                     3.   wait: change at the end of the last interval, when the current mode finishes




       PN# TBD               St. Jude Medical CRMD Confidential         October 16, 2011        Page 23
                     St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           DDP_46:   Before starting each interval defined by the Stage Spike Output command, the DDP
                     shall check for a handshake error. An error indication shall be returned if a handshake
                     error has occurred.
           DDP_47:   For any startup mode specified by the Stage Spike Output command, the DDP
                     interface shall complete the change to this new interval definition within 1 ms of
                     terminating the previous interval definition.
           DDP_51:   If the specified number of intervals by the Stage Spike Output command is 0, the
                     waveform shall repeat until another command (Stop Current Output or Stop All Output)
                     stops the output or until the interface is reset by an Finish Test or Abort Test
                     command.
           DDP_53:   While the stage buffer already holds an operation waiting via startup mode 2, the
                     Stage Spike Output command shall return an operating error indication for subsequent
                     mode 2 requests.
           DDP_55:   The previous staged operation shall always take precedence.
           DDP_57:   The Stage Spike Output command shall return a success or failure indication within 1
                     ms.
3.6.3.3.       Stop Current Output

           Additional information for the Stop Current Output command is provided here, supplementing the
           requirements provided in the Common Requirements section.

           DDP_59:   The Stop Current Output command shall terminate the output channel, returning it to a
                     digital zero value within 3 ms.
3.6.3.4.       Stop All Output
           Additional information for the Stop All Output command is provided here, supplementing the
           requirements provided in the Common Requirements section.




       PN# TBD              St. Jude Medical CRMD Confidential        October 16, 2011        Page 24
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           DDP_61:    The Stop All Output command shall terminate the output channel, returning it to a
                      digital zero value within 3 ms.
3.6.3.5.       Waveform Output Line
           DDP_77:    The DDP waveform output line shall return low on the last data point of each
                      waveform.
3.6.4. Data
           DDP_79:    The DDP interface shall collect the following data each time an interval/amplitude
                      waveform is started.
           field name               type              description
           system timetag           unsigned long Time the waveform output began.
           operation                enumerated        STAGE_WAVEFORM or
                                                      PLAY_WAVEFORM
           pre-waveform delay       unsigned long Delay before start of waveform
           waveform identifier      unsigned long The requested waveform identifier.
           sample repeat count      unsigned short The repeat count for each data sample.
           elapsed output time      unsigned long Time elapsed during waveform output
                                                      (PLAY_WAVEFORM only) or the startup
                                                      mode for the waveform: NOW, NEXT, or
                                                      WAIT (STAGE_WAVEFORM only)


           DDP_82:    The DDP interface shall collect the following data each time a waveform is loaded
                      from disk.
           field name              type               description
           system timetag          unsigned long Time the operation began.
           operation               enumerated         LOAD_WAVEFORM or
                                                      LOAD_NAMED_WAVEFORM
           waveform identifier     unsigned long The requested waveform identifier.
           file name               string             Name of the file used
                                                      (LOAD_NAMED_WAVEFORM only)


           DDP_81:    The DDP interface shall collect the following data each time a spike waveform is
                      started.
           field name              type               description
           system timetag          unsigned long Time the waveform output began.
           operation               enumerated         STAGE_SPIKE or PLAY_SPIKE
           Pre-waveform delay      unsigned long Delay before start of waveform
           Spike height            short              Digital spike amplitude.
           Elapsed output time     unsigned long Time elapsed during waveform output
                                                      (PLAY_SPIKE only) or the startup mode for
                                                      the waveform: NOW, WAIT, NEXT
                                                      (STAGE_SPIKE only)


           DDP_83:    The DDP interface shall collect the following data each time a Stop Current Output,
                      Stop All Output, or Wait For Idle command is executed.
           Field name               type               Description
           System timetag           unsigned long Time the operation began.
           operation                enumerated         STOP_CURRENT,
                                                       STOP_ALL, or
                                                       WAIT_FOR_IDLE

3.6.5. Performance and Timing

       PN# TBD               St. Jude Medical CRMD Confidential       October 16, 2011        Page 25
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           DDP_85:     The digitized DDP waveforms shall be output to the ICD's waveform analyzer at the
                       rate of 500 Hz.
           DDP_87:     The output waveforms in interval/amplitude mode shall be able to repeatably attain
                       intervals from 2 ms to an indefinite period.


3.6.6. Constraints

           No support for manual testing configurations will be provided.

           No support for atrial morphology channel or far field data stream is required.

           The DDP cannot recognize any “happenings”.

           All waveforms shall be read from disk before the DDP outputs the waveform, and all waveforms
           and interval specifications shall fit in memory.

           The user will have to pre-load waveform files through a function call during initialization in order for
           the real time performance requirements to be met. If the script interface has a confirm pass, then
           the pre-loading could possibly be done automatically. These constraints are needed to meet the
           real time performance requirements.



3.6.7. Dependencies
           DDP_97:     Before the DDP functional interface begins to output a waveform, it shall inform the
                       device to switch from the analog (HS) output to the digital (DDP) output. This switch
                       will prevent HS output from interfering with DDP output.
           DDP_99:     After the DDP functional interface finishes outputting the last waveform in the stage
                       buffer, it shall inform the device to switch from the digital (DDP) output to the analog
                       (HS) output. This switch will once again allow HS output to go through to the device.

3.8.       Digital Outputs
           The Digital Outputs interface provides a general capability to output digital signals. A major use
           for these outputs is to automatically control switches that were operated manually in previous ICD
           testing efforts.
3.8.1. Inputs
           There are no inputs to the Digital Outputs interface.
3.8.2. Outputs
           The outputs produced by the Digital Outputs functional interface are digital signals compatible with
           ICD signal levels and currents. These outputs control breadboard signals as described in the
           following subsections.

3.8.2.1.        Interface Box Reset
           Although telemetry is required to reset the ICD, a reset for the Neutrino EMT+ Interface Box is
           provided. The Interface Box routes and conditions many signals between the Neutrino EMT+ and
           the ICD breadboard.




       PN# TBD                St. Jude Medical CRMD Confidential         October 16, 2011         Page 26
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           DO_05:     The Interface Box Digital Output shall cause the Neutrino EMT+ interface box to be
                      reset.
           DO_07:     Interface Box Reset shall always be released when the Digital Outputs functional
                      interface is reset.
3.8.2.2.        Test Enable
           When asserted, the Test Enable signal allows full access to the ICD memory, but downloading of
           ICD firmware code is prevented. The ICD only allows code to be downloaded when Test Enable
           is cleared.

           DO_09:     When the Test Enable output is asserted, the signal to enable ICD testing shall be
                      produced.
           DO_11:     When the Digital Outputs interface is reset, the Test Enable line shall be in its inactive
                      state.
3.8.2.3.        Magnet Reed Switch
           In a production ICD, a suitable magnetic field is used to trip the reed switch. In the breadboard
           configuration, a reed switch equivalent is closed and opened.

           DO_13:     When the software reed switch digital output is in its “field present” state, the
                      breadboard reed switch shall be in the closed position.
           DO_15:     When the software reed switch digital output is in its “no field present” state, the
                      breadboard reed switch shall be in the open position.
           DO_17:     When the Digital Outputs functional interface is reset, the reed switch shall be in its
                      "no field present" state.
3.8.2.4.        Safe/Enable
           The safe/enable switch controls the draining of the charge on the high voltage capacitors.

           DO_19:     When the safe/enable digital output is in the “safe” state, the safe/enable switch shall
                      be in the “safe” position.
           DO_21:     When the safe/enable digital output is in the “enable” state, the safe/enable switch
                      shall be in the “enable” position.
           DO_23:     When the Digital Outputs interface is reset and at the end of each test, the safe/enable
                      output shall be placed in its "safe" mode. No other safety requirements or hazard
                      controls are provided.
           Any need to minimize the risk of exposure to high voltages shall be addressed directly in the test
           specifications.

3.8.2.5.        Logic Analyzer Trigger
           The logic analyzer trigger output controls the external sync signal to a logic analyzer.

           DO_25:     When the logic analyzer trigger digital output is asserted, the signal to trigger the logic
                      analyzer shall be produced.
           DO_27:     When the Digital Outputs interface is reset, the logic analyzer trigger shall be in its
                      inactive state.
3.8.2.6.        EMT Net / External Net Switch
           The EMT Net / External Net Switch allows dynamic switching between the Local Area Network
           (LAN) within the Neutrino EMT+ and the external St Jude network. Connection to the St Jude
           network should be used judiciously to minimize spurious traffic.

       PN# TBD                St. Jude Medical CRMD Confidential        October 16, 2011         Page 27
                       St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           DO_29:      When the EMT Net / External Net Switch output is asserted, the signal to disconnect
                       the EMT Net from the external St Jude network shall be produced.
           DO_31:      When the EMT Net / External Net Switch output is cleared, the signal to disconnect
                       the EMT Net from the external St Jude network shall be released.
           DO_33:      When the Digital Outputs interface is reset (typically at the start of a test), the EMT Net
                       / External Net Switch line shall be asserted (to disconnect the EMT Net from the
                       external St Jude network.
           DO_34:      When a test is completed, the EMT Net / External Net Switch line shall be released (to
                       connect the EMT Net to the external St Jude network).
3.8.3. Commands
           The Digital Outputs interface shall support commands in addition to those specified for all
           functional interfaces in the common requirements section. The interface supports access to its
           outputs as both dedicated and general purpose digital lines. Interface lines are hard-wired to
           achieve "mapping" of its lines to the dedicated functions specified in the Outputs subsection.

3.8.3.1.         Twiddle Digital Output
           DO_35:      The Twiddle Digital Output command controls any of the available output lines. The
                       following parameters are required to fully specify the operation.
            1.    Line Number: Specifies which output line to update.

            2.    Action. Specifies the action to take, either clear, set, or toggle.

           More meaningful names, such as ON, OFF, TOGGLE, SAFE, ENABLE, etc., may be provided via
           symbolic definitions within the script or C++ code. The Twiddle Digital Output command works in
           a “raw” mode to avoid the confusion of worrying about active high/low and the like at this level.

           DO_37:      The DO functional interface shall provide range checking for allowable parameter
                       ranges for the Twiddle Digital Output command.
           DO_38:      If the Twiddle Digital Output command is issued for the EMT Net / External Net Switch
                       line, a failure indication shall be returned.
           DO_39:      The new digital output line state shall be maintained until another Twiddle Digital
                       Output command updates it, the test finishes, or the interface is reset.
           DO_41:      No error indication shall be returned if the Twiddle Digital Output command requests a
                       new line state which is identical to the current line state. The Digital Outputs functional
                       interface shall service this command and set the line to the requested state.
           DO_43:      A success or failure indication shall be returned within 2 ms from the Twiddle Digital
                       Output command.
3.8.3.2.         Read Digital Output
           DO_45:      The Read Digital Output command reads the current status of any of the available
                       output lines. The following parameter is required to fully specify the operation.
            1.    Line Number: Specifies which output line to read.




       PN# TBD                St. Jude Medical CRMD Confidential          October 16, 2011       Page 28
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           DO_47:     The DO functional interface shall provide range checking for allowable parameter
                      ranges for the Read Digital Output command.
           DO_49:     A success or failure indication shall be returned within 2 ms from the Read Digital
                      Output command.
3.8.4. Data
           DO_51:     The Digital Outputs interface shall collect the following data for each command that it
                      executes.
           field name               type              Description
           system timetag           unsigned long Time that the function was performed.
           Operation                enumerated        function performed, either TWIDDLE_DO or
                                                      READ_DO
           line number              unsigned short Line number that was twiddled or read.
           line state               unsigned short State of the line after command is performed:
                                                      0 or 1.
3.8.5. Performance and Timing
           DO_55:     After a transition, the signal output shall stabilize within 10 s.
3.8.6. Constraints
           Because the Magnet Reed Switch is simulated without actually using a magnetic field, interaction
           with telemetry cannot be tested.

           The EMT Net / External Net Switch line is for use only outside of an active EMT program.
           Connection to the external St Jude network will primarily be used for file transfer. EMT test
           program traffic is not allowed to go out to the external St Jude network. A separate utility will be
           needed to control this line.
3.8.7. Dependencies
           The Digital Outputs interface depends on the test specification to know which general purpose
           lines have been assigned to dedicated functions.

3.9.       Digital Inputs
           The Digital Inputs (DI) interface tracks various signals available from the breadboard ICD. The DI
           interfaces logs data samples for these signals, and also recognizes “happenings” when the states
           of all input signals matches a condition mask.

           The transition tracking and happening recognition requirements are independent and have
           different performance requirements.
3.9.1. Inputs
           A total of 96 digital input lines are supported for the Neutrino EMT+.

           These lines are assigned in the manner described below:

3.9.1.1.        Diagnostic “Flex” Ports
           Diagnostic flex ports account for 80 lines organized as eight byte-wide ports that latch data written
           to them by the ICD software. These are general purpose inputs whose function is defined by the
           embedded software.




       PN# TBD               St. Jude Medical CRMD Confidential          October 16, 2011       Page 29
                             St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           DI_03:            Digital Input lines located in flex ports shall be bit-wise maskable within each port.
3.9.1.2.             Miscellaneous Signals
           DI_05:            Miscellaneous Signals are grouped together into this list. Individual hardware mask
                             control shall be provided for each of these inputs.
           Up to 16 mask control lines should be planned for.

               1.     APACE: Digital signal corresponding to a pace pulse in the atrium.

               2.     RVPACE: Digital signal corresponding to a pace pulse in the right ventricle.

               3.     LVPACE: Digital signal corresponding to a pace pulse in the left ventricle.

               4.     ASENSE: Digital signal corresponding to a sensed pulse in the atrium.

               5.     VBSENSE: Digital signal corresponding to a Brady sensed pulse in the ventricle.

               6.     VTSENSE: Digital signal corresponding to a Tachy sensed pulse in the ventricle.

               7.     VDEFIB1: Digital signal corresponding to a positive high voltage pulse in the ventricle.

               8.     VDEFIB2: Digital signal corresponding to a negative high voltage pulse in the ventricle.

               9.     CHARGE: This is the oscillator signal that is active during HV capacitor charging for either
                      atrial or ventricular HV shocks, but converted to an active high charging indicator that
                      doesn't oscillate.
               10.
               11. SYNC: An input from the LAC interface indicating that its trigger conditions were just
                   satisfied.

               12. EVKD_RSP1: Digital signal corresponding to a backup pace pulse in the ventricle.

               13. EVKD_RSP2: Digital signal corresponding to an evoked response in the ventricle.



                   DI_07:        MISC_PORT (port DPA<7..0> of the “DI Flex Ports” PCI-DIO-96 adapter)

                                    Signal                               Bit

                                   APACE                                  0

                                  RVPACE                                  1

                                  ASENSE                                  2

                                 VBSENSE                                  3

                                  VTSENSE                                 4

                                  LVPACE                                  5

                          MISC1_RESERVED1                                 6

       PN# TBD                      St. Jude Medical CRMD Confidential         October 16, 2011         Page 30
            St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.



            MISC1_RESERVED2                              7



         MISC_PORT2 (port CPA<7..0> of the “DI Flex Ports” PCI-DIO-96 adapter)

                   Signal                               Bit

                    SYNC                                 0

                EVKD_RSP1                                1

                EVKD_RSP2                                2

            MISC2_RESERVED1                              3

            MISC2_RESERVED2                              4

                  VDEFIB1                                5

                  VDEFIB2                                6

                  CHARGE                                 7



    FLEXPORT0 (port APC<7..0>) of the “DI Flex Ports” PCI-DIO-96 adapter)

    FLEXPORT1 (port BPC<7..0>) of the “DI Flex Ports” PCI-DIO-96 adapter)

    FLEXPORT2 (port APB<7..0>) of the “DI Flex Ports” PCI-DIO-96 adapter)

    FLEXPORT3 (port BPB<7..0>) of the “DI Flex Ports” PCI-DIO-96 adapter)

    FLEXPORT4 (port APA<7..0>) of the “DI Flex Ports” PCI-DIO-96 adapter)

    FLEXPORT5 (port BPA<7..0>) of the “DI Flex Ports” PCI-DIO-96 adapter)

    FLEXPORT6 (port CPC<7..0>) of the “DI Flex Ports” PCI-DIO-96 adapter)

    FLEXPORT7 (port DPC<7..0>) of the “DI Flex Ports” PCI-DIO-96 adapter)

    FLEXPORT8 (port CPB<7..0>) of the “DI Flex Ports” PCI-DIO-96 adapter)

    FLEXPORT9 (port DPB<7..0>) of the “DI Flex Ports” PCI-DIO-96 adapter)


DI_09:
 A total of 32 DI flex port control (output) lines shall be supported for the Neutrino EMT+:

    PRT_ALTADDR (8 bits) (port DPB<7..0> of the “DO/DDP/DAS/FLEX_CNTRL” PCI-DIO-96
     adapter)


PN# TBD            St. Jude Medical CRMD Confidential         October 16, 2011         Page 31
                          St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


                   PRT_ADR<7..0> (8 bits) (port CPC<7..0> of the “DO/DDP/DAS/FLEX_CNTRL” PCI-DIO-96
                    adapter)

                   PRT_ADR<15..8> (8 bits) (port DPC<7..0> of the “DO/DDP/DAS/FLEX_CNTRL” PCI-DIO-96
                    adapter)

                   READ_PRT (1 bit) (port BPB<6> of the “DO/DDP/DAS/FLEX_CNTRL” PCI-DIO-96 adapter)

                   WRITE_PRT (1 bit) (port BPB<5> of the “DO/DDP/DAS/FLEX_CNTRL” PCI-DIO-96 adapter)

                   STROBE (1 bit) (port BPB<4> of the “DO/DDP/DAS/FLEX_CNTRL” PCI-DIO-96 adapter)

           PADR_SELECT (4 bits) (port BPB<3..0> of the “DO/DDP/DAS/FLEX_CNTRL” PCI-DIO-96
                   adapter)


3.9.2. Outputs
           There are no outputs from the DI interface to the ICD.
3.9.3. Commands
           The Digital Inputs interface shall support commands in addition to those specified for all functional
           interfaces in the common requirements section.

3.9.3.1.            Mask Flex Port
           DI_13:          The Mask Flex Port command defines the subset to monitor among the signals in a
                           flex port. Two parameters shall be included to fully specify conditions.
               1.     port: Specifies the flex port number. Valid range is 0-9.

               2.     transition monitor mask: Specifies, for each line within this port, whether transitions of the
                      line are to be collected.

           DI_15:          The DI functional interface shall provide range checking for allowable parameter
                           ranges for the Mask Flex Port command.
           DI_17:          Masked bits shall be held in a zero logic state after the Mask Flex Port command has
                           completed.
           DI_19:          When a line is masked by the Mask Flex Port command, it shall be masked for both
                           transition tracking and happening recognition.
           DI_21:          The new mask shall take effect immediately on execution of the Mask Flex Port
                           command without disturbing data samples that have already been collected.
           DI_23:          A success or failure indication shall be returned within 2 ms from the Mask Flex Port
                           command.
3.9.3.2.            Mask Miscellaneous Port
           DI_25:          The Mask Miscellaneous Port command defines the subset to monitor among the
                           signals in the first miscellaneous port . A single parameter shall be included to fully
                           specify conditions.
               1.     transition monitor mask: Specifies, for each miscellaneous line monitored by the interface,
                      whether transitions of the line are to be collected.




       PN# TBD                    St. Jude Medical CRMD Confidential        October 16, 2011         Page 32
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           DI_27:      The DI functional interface shall provide range checking for allowable parameter
                       ranges for the Mask Miscellaneous Port command.
           DI_29:      Masked bits shall be held in a zero logic state after the Mask Miscellaneous Port
                       command has completed.
           DI_31:      When a line is masked by the Mask Miscellaneous Port command, it shall be masked
                       for both transition tracking and happening recognition.
           DI_33:      The new mask shall take effect immediately on execution of the Mask Miscellaneous
                       Port command without disturbing data samples that have already been collected.
           DI_35:      A success or failure indication shall be returned within 2 ms from the Mask
                       Miscellaneous Port command.


3.9.3.3.         Mask Second Miscellaneous Port
           DI_25a:     The Mask Second Miscellaneous Port command defines the subset to monitor among
                       the signals in the second miscellaneous port. A single parameter shall be included to
                       fully specify conditions.
            2.    transition monitor mask: Specifies, for each miscellaneous line monitored by the interface,
                  whether transitions of the line are to be collected.

           DI_27a:     The DI functional interface shall provide range checking for allowable parameter
                       ranges for the Mask Second Miscellaneous Port command.
           DI_29a:     Masked bits shall be held in a zero logic state after the Mask Second Miscellaneous
                       Port command has completed.
           DI_31a:     When a line is masked by the Mask Second Miscellaneous Port command, it shall be
                       masked for both transition tracking and happening recognition.
           DI_33a:     The new mask shall take effect immediately on execution of the Mask Second
                       Miscellaneous Port command without disturbing data samples that have already been
                       collected.
           DI_35a:     A success or failure indication shall be returned within 2 ms from the Mask Second
                       Miscellaneous Port command.


3.9.3.4.         Set Flex Port Address
           DI_37:      The Set Flex Port Address command sets the address within the ICD to be monitored
                       at this flex port. Three parameters shall be included to fully specify conditions.
            1.    port: Specifies the flex port number. Valid range is 0-9.

            2.    address: Specifies the ICD address to be monitored at this flex port. Valid range is 0-
                  16777215 (0xFFFFFF).

            3.    acquisition mode: Specifies the time at which data is latched off of the ICD’s data bus.
                  There are three modes: R (latch on read), W (latch on write), and RW (latch on both reads
                  and writes).




       PN# TBD               St. Jude Medical CRMD Confidential        October 16, 2011       Page 33
                        St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           DI_38:        When the Set Flex Port Address command is executed in the “R” acquisition mode”,
                         the value reflected to the designated flex port is updated with the data on the ICD’s
                         data bus whenever data is read from the desired address.
           DI_39:        When the Set Flex Port Address command is executed in the “W” acquisition mode,
                         the value reflected to the designated flex port is updated with the data on the ICD’s
                         data bus whenever data is written to the desired address.
           DI_41:        When the Set Flex Port Address command is executed in the “RW” acquisition mode,
                         the value reflected to the designated flex port is updated with the data on the ICD’s
                         data bus whenever data is written to or read from the desired address.
           DI_42:        A success or failure indication shall be returned within 10 ms from the Set Flex Port
                         Address command.
3.9.3.5.        Reset Flex Ports
           DI_121:       The Reset Flex Ports command shall zero the data within all flex ports. No
                         parameters are required.
           DI_123:       The Reset Flex Ports command shall set the address for each flex port to a safe
                         address. This address shall be one to which data cannot be written.
           DI_125:       The Reset Flex Ports command shall set the acquisition mode to “W,” thus preventing
                         any data from changing until the user changes the address or acquisition mode.


           DI_131:       A success or failure indication shall be returned within 10 ms from the Reset Flex
                         Ports command.
           3.9.3.5.1.
3.9.3.6.        Read All DI Ports
           DI_61:        When the Read All DI Ports command is requested, the DI interface shall read the
                         status of all twelve byte ports. Twelve bytes of data are returned.
           Note that the data value from lines that are currently masked will be reported as a zero.

           DI_62:        A success or failure indication shall be returned within 2 ms from the Read All Ports
                         command.
3.9.3.7.        Read DI Word
           DI_63:        When the Read DI Word command is requested, the DI interface shall read the status
                         of the two corresponding byte ports. One parameter is required.
               1.       word number: Specifies which of the six words will be read.
                              word 0 = ports 0, 1
                              word 1 = ports 2, 3
                              word 2 = ports 4, 5
                              word 3 = ports 6, 7
                              word 4 = ports 8, 9
                              word 5 = ports 10, 11



           One word of data is returned.

           Note that the data value from lines that are currently masked will be reported as a zero.




       PN# TBD                 St. Jude Medical CRMD Confidential        October 16, 2011        Page 34
                          St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


           DI_65:          A success or failure indication shall be returned within 2 ms from the Read DI Word
                           command.
3.9.3.8.         Read DI Port
           DI_67:         When the Read DI Port command is requested, the DI interface shall read the status
                          of the corresponding byte port. One parameter is required.
                 1.      port number: Specifies which of the twelve ports will be read.

           One byte of data is returned.

           Note that the data value from lines that are currently masked will be reported as a zero.

           DI_69:          A success or failure indication shall be returned within 2 ms from the Read DI Port
                           command.
3.9.3.9.         Specify DI Happening Conditions
           DI_71:          The Specify DI Happening Conditions command specifies a set of conditions that the
                           interface shall recognize as a happening. Detection based on the conditions is only
                           enabled by the Check For Happening and Wait For Happening commands. The
                           following parameters shall be included to fully specify conditions.
            1.        happening ID: numerical identifier for the happening.

            2.        port number: This identifies one of the twelve ports that the interface monitors for each
                      happening. Each port is eight bits wide.

            3.        condition mask: Specifies what condition of the line contributes to the happening.

           The happening is recognized when all lines of all ports meet their specified condition
           simultaneously.

           DI_73:          The DI functional interface shall provide range checking for allowable parameter
                           ranges for the Specify DI Happening Conditions command.
           DI_75:          The DI interface shall support local storage for and monitoring of up to eight
                           simultaneous happening specifications.
           DI_77:          The DI interface shall support the following happening conditions for each line, in any
                           combination.
            1.        low state

            2.        high state

            3.        rising edge

            4.        falling edge

            5.        don't care

           Note that the "don't care" line condition serves the same purpose for happenings that the mask
           control commands provide for both transitions and happenings.




       PN# TBD                       St. Jude Medical CRMD Confidential     October 16, 2011        Page 35
                 St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


      DI_78:     DI happening shall initially be disabled. The conditions for all lines within that
                 happening shall be initialized to "don't care."
      DI_79:     A success or failure indication shall be returned within 2 ms from the Specify DI
                 Happening Conditions command.
3.9.4. Data
      DI_81:     The Neutrino EMT+ shall collect the time tag corresponding to recognized happenings.
                 The following information shall be saved for each recognized happening.
      field name                type              Description
      system timetag            unsigned long System time of happening detection.
      Operation                 enumerated        DI_HAPPENING
      happening ID              unsigned short Identifier for satisfied happening.
      DI_83:     The Digital Inputs interface shall record every digital signal transition that appears
                 among its unmasked input lines. The following information shall be saved for each
                 transition.
      field name                type              Description
      system timetag            unsigned long System time.
      Operation                 enumerated        DI_TRANSITION
      byte 0                    unsigned short State of input byte 0 after the transition.
      byte 1                    unsigned short State of input byte 1 after the transition.
      byte 2                    unsigned short State of input byte 2 after the transition.
      byte 3                    unsigned short State of input byte 3 after the transition.
      byte 4                    unsigned short State of input byte 4 after the transition.
      byte 5                    unsigned short State of input byte 5 after the transition.
      byte 6                    unsigned short State of input byte 6 after the transition.
      byte 7                    unsigned short State of input byte 7 after the transition.
      byte 8                    unsigned short State of input byte 8 after the transition.
      byte 9                    unsigned short State of input byte 9 after the transition.
      byte 10                   unsigned short State of input byte 10 after the transition.
      byte 11                   unsigned short State of input byte 11 after the transition.
      DI_85:     The following information shall be recorded when a Digital Inputs masking operation is
                 performed.
      field name                type              description
      system timetag            unsigned long System time.
      operation                 enumerated        MASK_FLEX_PORT or
                                                  MASK_MISC_PORT
      port                      unsigned short Port that was masked
      mask                      unsigned short Byte-wide mask
      DI_87:      The following information shall be recorded when a Set Flex Port Address command
                  is performed.
      field name                 type              description
      system timetag             unsigned long System time.
      operation                  enumerated        SET_FLEX_PORT_ADDR
      port                       unsigned short Port that was set
      address                    unsigned long 24 bit ICD address
      acquisition mode           enumerated        R, W, or RW
      DI_88:     The following information shall be recorded when a Reset Flex Ports command is
                 performed.
      field name                type              description
      system timetag            unsigned long System time.
      operation                 enumerated        RESET_FLEX_PORTS



     PN# TBD            St. Jude Medical CRMD Confidential         October 16, 2011         Page 36
                St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


     DI_89:      The Digital Inputs interface shall save the results of each read of the digital signal state
                 when a Read All DI Ports command is executed. The following information shall be
                 saved.
     field name                 type              description
     system timetag             unsigned long System time.
     operation                  enumerated        READ_ALL_DI
     byte 0 data                unsigned short State of input byte 0.
     byte 1 data                unsigned short State of input byte 1.
     byte 2 data                unsigned short State of input byte 2.
     byte 3 data                unsigned short State of input byte 3.
     byte 4 data                unsigned short State of input byte 4.
     byte 5 data                unsigned short State of input byte 5.
     byte 6 data                unsigned short State of input byte 6.
     byte 7 data                unsigned short State of input byte 7.
     byte 8 data                unsigned short State of input byte 8.
     byte 9 data                unsigned short State of input byte 9.
     byte 10 data               unsigned short State of input byte 10.
     byte 11 data               unsigned short State of input byte 11.
     DI_91:     The Digital Inputs interface shall save the results of each read of the digital signal state
                when a Read DI Word command is executed. The following information shall be
                saved.
     field name                type              description
     system timetag            unsigned long System time.
     operation                 enumerated        READ_DI_WORD
     word                      unsigned short Word that was read
     data                      unsigned short State of the word.
     DI_93:     The Digital Inputs interface shall save the results of each read of the digital signal state
                when a Read DI Port command is executed. The following information shall be saved.
     field name                type              description
     system timetag            unsigned long System time.
     operation                 enumerated        READ_DI_PORT
     port                      unsigned short Port that was read
     data                      unsigned short State of port
     DI_95:     The following information shall be recorded when command to enable or disable the
                extra DI miscellaneous lines is performed.
     field name                type              description
     system timetag            unsigned long System time.
     operation                 enumerated        ENABLE_EXTRA_MISC or
                                                 DISABLE EXTRA_MISC
     DI_97:     The following information shall be recorded when a Specify DI Happening Conditions
                command is performed.
     field name                type              description
     system timetag            unsigned long System time.
     operation                 enumerated        SPEC_DI_HAPP
     happening ID              unsigned short Requested happening
     port                      unsigned short Port whose conditions are specified
     condition mask            string            Eight character mask
3.9.5. Performance and Timing
     DI_99:      The DI functional interface shall be able to record and time tag any transition of a
                 Digital Input signal with 100 microsecond resolution. Specifically, lines shall be
                 sampled every 100 microseconds (plus or minus 20 microseconds).



     PN# TBD            St. Jude Medical CRMD Confidential         October 16, 2011         Page 37
                  St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


      DI_105:      The Digital Inputs functional interface shall be able to record and time tag any Digital
                   Input happening with 100 microsecond resolution.
      DI_107:      Latency in reporting a happening detected by the Digital Inputs functional interface
                   shall not exceed 1 ms. (Thus, repeatability is guaranteed within 1 ms.)




      DI_108a:
      The DI functional interface shall be operational within five seconds of program initiation. No
      initialization script shall be required to initiate operation of the DI functional interface.


      DI_108b:
      During normal operations, the DI functional interface shall not incur data overrun errors. Here,
      “normal operations” means without attempting to deliberately cause data overruns by, for
      instance, altering the correct setup of the EMT+ hardware or software.


      DI_108c:
      The DIEnableExtraLines and DIDisableExtraLines API functions shall have no operational effect
      on the DI functional interface. These calls shall log an information-only message stating that
      these API calls are no longer supported in EMT+ and should be removed from the user’s test
      program.



      DI_108d:
      The DI functional interface shall be able to support execution of a test of up to 59 hours and 39
      minutes in length.


3.9.6. Constraints
      Digital Input lines are not latched. The purpose of the Digital Inputs interface is to track activity on
      the lines in real time. Tracking of transitions that occur faster than the acquisition rate is out of
      scope.

      DI_109:     If a command from the following list is requested while the Digital Inputs functional
                  interface is in a non-blocking happening mode, an error indication shall be returned.
                 Reset Flex Ports
                 Specify DI Happening Conditions
                 Set Flex Port Address

      The user shall first issue the Stop Happening command to terminate the non-blocking happening
      operating mode before these commands may be executed.
3.9.7. Dependencies
      The DI interface provides the primary means for gathering digital status information from the ICD.
      The Engineering Programmer interface provides a slower and more indirect alternative. The
      interface to the logic analyzer provides a view of the internal ICD signals, but it is less integrated
      into the Neutrino EMT+ than the DI interface.



     PN# TBD              St. Jude Medical CRMD Confidential        October 16, 2011         Page 38
                   St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.10. Logic Analyzer Communication
        A logic analyzer monitors digital bus traffic internal to the ICD.              The Logic Analyzer
        Communication (LAC) Interface integrates this function into the Neutrino EMT+. Only the
        breadboard configuration is capable of providing these inputs to the logic analyzer. The logic
        analyzer is different from the Digital Inputs interface in two main ways: its inputs may transition at
        much higher frequencies, and sampling shall be synchronized with the ICD microprocessor bus
        clock.

        Functional requirements for the LAC interface are essentially those of a high performance logic
        timing and state analyzer. This document does not attempt to express those requirements.
        Instead, we specify requirements to integrate such a device into the Neutrino EMT+ so that it can
        interact with other functional interfaces in a consistent fashion.

        The LAC interface provides the primary means for monitoring ICD RAM and register contents
        during a test. The Engineering Programmer interface provides a slower and more indirect
        alternative.
3.10.1.          Inputs
        LAC_03:    The LAC interface shall acquire all address, data, and control signals from the
                   breadboard microprocessor bus.
        The requirement is met through the use of a logic analyzer subsystem. A data connection (such
        as RS-232C or GPIB) and an external trigger indication are required inputs to the Neutrino EMT+
        from the logic analyzer. The external trigger indication is to be routed to the Digital Inputs
        interface.
3.10.2.          Outputs
        There are no outputs from the LAC interface to the ICD. If a logic analyzer subsystem is used, a
        data connection and an external trigger source are required outputs from the Neutrino EMT+ to
        the logic analyzer. The external trigger is to be provided via a dedicated line from the Digital
        Outputs interface. This output allows the test developer to arm and disarm the interface under
        program control (assuming that the logic analyzer subsystem has been set up to include the
        external source as part of its trigger specifications). Real time arming is supported, but subject to
        the general 10 ms constraint for response time. High speed arming control, achieved by direct
        point to point connections, will not be supported by the Neutrino EMT+.
3.10.3.          Commands
        The LAC interface shall support commands in addition to those specified for all functional
        interfaces in the common requirements section. Some requirements for the LAC interface are
        met by using Digital Outputs interface commands.

3.10.3.1.    Load Logic Analyzer Setup
        LAC_05:     The Load Logic Analyzer Setup command shall instruct the LAC interface to download
                    a previously defined setup into the logic analyzer. A single parameter is required for
                    Load Logic Analyzer Setup.
            1.    file name: Specifies the source file from which the setup is downloaded. The file shall
                  conform to the logic analyzer's format requirements. The name shall conform to
                  Windows NT standards for a full path or relative path specification.

        Neutrino EMT+ users will define setups from the logic analyzer's front panel in conjunction with a
        stand-alone utility that issues the Save Logic Analyzer Setup command. The logic analyzer setup
        includes line setup and trigger specification information. This utility is specified in the User
        Interface section.



       PN# TBD            St. Jude Medical CRMD Confidential         October 16, 2011        Page 39
                          St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


        LAC_07:           The LAC functional interface shall be able to download a setup regardless of the
                          current state of the logic analyzer, as long as the logic analyzer is functioning correctly.
        LAC_11:           A success or failure indication shall be returned to the Test Controller within ten
                          seconds from the Load Logic Analyzer Setup command.
3.10.3.2.        Save Logic Analyzer Setup
        The Save Logic Analyzer Setup command instructs the LAC interface to upload the current setup
        from the logic analyzer. It will only be issued from a stand-alone utility program to provide data
        files for later use during a test by the Load Logic Analyzer Setup command.

        LAC_13:           Two parameters are required for the Save Logic Analyzer Setup command.
            1.        file name: Specifies the destination file in which to save the setup. The name shall
                      conform to Windows NT standards for a full or relative path specification.

            2.        overwrite flag: TRUE/FALSE - Specifies whether to overwrite an existing setup file of the
                      same name.

        LAC_15:           The LAC functional interface shall provide range checking for the overwrite flag
                          parameter for the Save Logic Analyzer Setup command.
        LAC_17:           The Save Logic Analyzer Setup overwrite option shall default to TRUE.
        LAC_21:           A success or failure indication shall be returned within ten seconds from the Save
                          Logic Analyzer Setup command.
3.10.3.3.        Save Trace Listing
        LAC_23:           The Save Trace Listing command instructs the LAC interface to upload the logic
                          analyzer's trace buffer contents. One parameter is required.
            1.        file name: Specifies the destination file where the trace buffer will be stored. The name
                      shall conform to Windows NT standards for a full or relative path specification.

        LAC_27:           If the specified destination file already exists, it shall be overwritten by the Save Trace
                          Listing command without warning.
        LAC_29:           A success or failure indication shall be returned within 60 seconds from the Save
                          Trace Listing command.
3.10.3.4.        Load Logic Analyzer Symbols
        LAC_31:            The Load Logic Analyzer Symbols command shall instruct the LAC interface to
                           download a previously defined symbol table into the logic analyzer. A single
                           parameter is required for Load Logic Analyzer Symbol.
                 1.      file name: Specifies the source file from which the setup is downloaded. The name
                         shall conform to Windows NT standards for a full path specification.

        Neutrino EMT+ users will define symbols in an ASCII file that can be interpreted to send the
        proper instructions to the logic analyzer.




       PN# TBD                   St. Jude Medical CRMD Confidential         October 16, 2011         Page 40
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


        LAC_33:        The LAC functional interface shall be able to download the symbol table regardless of
                       the current state of the logic analyzer, as long as the logic analyzer is functioning
                       correctly and does not require a complete reset.
        LAC_35:        The LAC functional interface shall provide range checking for allowable parameter
                       ranges for the Load Logic Analyzer Symbols command.
        LAC_37:        A success or failure indication shall be returned to the Test Controller within ten
                       seconds from the Load Logic Analyzer Symbols command.
3.10.3.5.        Send Logic Analyzer Command
        Sometimes, Neutrino EMT+ users may want to control the logic analyzer in ways that were
        unanticipated by Neutrino EMT+ designers! The Send Logic Analyzer command is a general
        purpose command which provides a simple way to help these users.

        LAC_39:        The Send Logic Analyzer Command command instructs the LAC interface to send the
                       provided logic analyzer command directly to the logic analyzer. One parameter is
                       required.
            1.    logic analyzer command: Specifies the string to be sent to the logic analyzer.

        LAC_43:        The Send Logic Analyzer Command command shall wait until the logic analyzer has
                       responded to the command
        LAC_45:        A success or failure indication shall be returned within 60 seconds from the Send
                       Logic Analyzer Command command.
        LAC_46:        The string received from the logic analyzer shall be returned in response to the Send
                       Logic Analyzer Command command.
        LAC_47:        If no string is returned from the logic analyzer to the LAC interface in response to the
                       Send Logic Analyzer Command command, a null string shall be returned.
3.10.4.            Data
        LAC_48:        The following information shall be saved when the LAC interfaces, with the exception
                       of Save Logic Analyzer Setup, performs an action.

        field name                   type               description
        system timetag               unsigned long      System time.
        file name                    string             Name of the file used.
        operation                    enumerated         function performed, either
                                                        LOAD_LA_SETUP, SAVE_TRACE_LIST


        Data contained in the setup files are in binary format; they are only for use to restore setup
        configurations to the logic analyzer. Trace listings contain information acquired by the logic
        analyzer; the Neutrino EMT+ does not need to understand these contents either.
3.10.5.            Performance and Timing
        LAC_50:        The LAC interface shall be able to sync on a 100 kHz clock signal. It shall be able to
                       trigger on arbitrary input patterns or pattern sequences, and provide external
                       notification of a trigger at the time of detection. Trigger conditions shall be checked on
                       every clock cycle. External notification shall be recognized within 100 s.
3.10.6.            Constraints
        The Save Logic Analyzer Setup command should not be requested during a test.




       PN# TBD                St. Jude Medical CRMD Confidential        October 16, 2011         Page 41
                   St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


      The Neutrino EMT+ will treat the setup file contents as arbitrary data; only the logic analyzer
      interprets the data's meaning.

      The Neutrino EMT+ will treat the trace listing file contents as arbitrary data, but a human-readable
      format is preferred over a binary format.

      It is probably not feasible to retrieve the symbols saved within the logic analyzer. The symbols file
      should be created manually (and hopefully shared).

      The Neutrino EMT+ is not responsible for the results of the logic analyzer command sent as a
      result of executing the Send Logic Analyzer Command!
3.10.7.         Dependencies
      The ability to disassemble a code trace into equivalent assembly language mnemonics is a
      desirable attribute for the LAC interface. The ability to accept symbolic address references in a
      trigger condition is also a desired attribute, but not a requirement.

      In order to meet the LAC interface requirements, the logic analyzer subsystem should include the
      following features.

          1.   External trigger output from the Engineering Mode Tester to arm the logic analyzer.
               Analyzers usually refer to this as an external trigger source.

          2.   External trigger input from the logic analyzer to provide a stimulus for happenings. This
               input would be routed to the Digital Inputs interface.

          3.   Ability to save locally defined logic analyzer setups by transmission through an external
               interface.

          4.   Ability to load logic analyzer setups by reception through an external interface.

          5.   Ability to save trace buffer contents captured during a test through an external interface.

      Arming under program control during a test will require an output from the Digital Outputs
      interface, connected to the logic analyzer's external trigger source. This feature also depends on
      correct definition of the trigger specifications. If the external trigger source is not included as part
      of the criteria, the Neutrino EMT+ Digital Output will be ignored.

      Recognition of happenings from the LAC interface will be the responsibility of the Digital Inputs
      interface, by connection to the logic analyzer external trigger indication.

      The LAC interface should take advantage of any features the logic analyzer provides to verify
      correctness of the data transfer.



      Breadboard Address Recorder (BAR) Communication
      The BAR Communication interface uploads data from the BAR.

      BRC_07:       The BAR Communication interface shall check that the BAR executes the requested
                    operations.
3.27.1.         Inputs
      The BARC interface receives data from a serial link to the BAR.



      PN# TBD              St. Jude Medical CRMD Confidential        October 16, 2011         Page 42
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.27.2.            Outputs
        The BARC interface outputs commands across a serial link to the BAR.
3.27.3.            Commands
        The BARC interface shall support commands in addition to those specified for all functional
        interfaces in the common requirements section.

3.27.3.1.        Check BAR
        BRC_09:       The Check BAR command shall send a command over the serial link to instruct the
                      BAR to report its status. No parameters are required.
        BRC_11:       If the BAR, in response to the request to report its status, reports that it is operational,
                      the Check BAR command shall return a successful indication.
        BRC_13:       If the BAR, in response to the request to report its status, reports that it is not
                      operational, the Check BAR command shall return a failure indication.
3.27.3.2.        Reset BAR
        BRC_14:
        The Reset BAR command shall send a command over the serial link to instruct the BAR to reset
        itself. No parameters are required.

There is no normal use for this command. It is provided as a potential convenience to the user, as there is
otherwise no way to reset the BAR except by powering it down and then back up. Note, however, that this
command will fail if the BAR is unable to communicate over the serial link. This limits the command’s
usefulness.
3.27.3.3.        Clear BAR Data
        BRC_15:       The Clear BAR Data command shall send a command over the serial link to instruct
                      the BAR to clear all its data. No parameters are required.
3.27.3.4.        Save BAR Data
        BRC_17:       The Save BAR Data command shall receive data from the serial link to the BAR, and
                      then save that data to a file.
            BRC_19: Two parameters are required for the Save BAR Data command.
            1.    file name: Specifies the destination file in which to save the data. The name shall conform
                  to Windows NT standards for a full path specification.

            2.    overwrite flag: TRUE/FALSE - Specifies whether to overwrite an existing data file of the
                  same name.




       PN# TBD               St. Jude Medical CRMD Confidential          October 16, 2011          Page 43
                   St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


        BRC_21:    If the overwrite flag parameter for the Save BAR Data command is FALSE and a file
                   with that name exists, then an error indication shall be returned.
        BRC_23:     The following information shall be saved to the head of a file by the Save BAR Data
                    command:
        field name                 width (# bytes) type               description
        version label              2                 unsigned short   data range [1, 65,535]
        pointer to start of data   2                 unsigned short   has a constant value of 30, the
                                                                      sum of the header field widths

        date and time            20                string             date and time when header is
                                                                      written to file (Null-terminated
                                                                      string of format:
                                                                      “MM/DD/YYYY-HH:MM:SS”)
        BAR version              2                 unsigned short     data range is unspecified
        raw/combined indicator   2                 unsigned short     has a constant value of 0
        file count               2                 unsigned short     has a constant value of 0
        the uploaded BAR data    unspecified       binary             the raw uploaded BAR data

        (The unsigned short fields are two bytes in Intel format: low order byte, followed by high order
        byte.)

3.27.3.5.   Acquire BAR Data
        BRC_25:    The Acquire BAR Data command shall send a command over the serial link to instruct
                   the BAR to begin acquiring data. No parameters are required.
3.27.3.6.   Stop Acquire Mode
        BRC_26:    The Stop Acquire command shall send a command over the serial link to instruct the
                   BAR to stop acquiring data. No parameters are required.




       PN# TBD            St. Jude Medical CRMD Confidential        October 16, 2011        Page 44
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.27.4.          Data
      BRC_27:         The following information shall be saved when the BARC interface performs an
                      operation on a file.

      field name                    type             description
      system timetag                unsigned long    System time.
      operation                     enumerated       function performed, i.e.
                                                     BARSaveData
      file name                     string           Name of the file used.
      function result               string           result of command execution, i.e.
                                                     Overwrite is Allowed or
                                                     Overwrite is not Allowed
      BRC_29:         The following information shall be saved when the BARC interface performs an
                      operation that does not involve a file.

      field name                    type             description
      system timetag                unsigned long    System time.
      operation                     enumerated       function performed, either
                                                     BARClear,
                                                     BARReset,
                                                     BARCheck,
                                                     BARSetAcquireMode, or
                                                     BARSetSaveMode
      function result               string           result of command execution


      Possible function results for the above operations are as follows:
          Operation                 Function Result
          BARClear                  none or
                                    IGNORED (Not in save mode)
          BARReset                  none
          BARCheck                  Passed,
                                    Failed, or
                                    Breadboard Not Connected
          BARSetAcquireMode         Set or
                                    Set FAILED
          BARSetSaveMode            Set or
                                    Set FAILED


3.27.5.          Constraints
      BRC_31:         An error indication shall be returned if the Clear BAR Data command is attempted
                      while the BAR is in the process of acquiring data.
3.28. Digital Activity Sensor
      The Digital Activity Sensor (DAS) simulates the operation of the mechanical activity sensor in the
      device. Instead of shaking the ICD, the DAS functional interface generates an oscillating signal
      that is counted by a circuit on the ICD breadboard.

      DAS_15:         The Neutrino EMT+ shall be able to start, change, or terminate DAS output in
                      response to any therapy input, telemetry message, or other time tagged event. The


      PN# TBD               St. Jude Medical CRMD Confidential       October 16, 2011       Page 45
                   St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


                   flexibility to meet this requirement is provided by this interface in coordination with the
                   Test Controller interface.
3.28.1.          Inputs
        There are no inputs into the DAS interface.
3.28.2.          Outputs
        DAS_21:    The Neutrino EMT+ shall be able to deliver preprogrammed sequences of output
                   waveforms. These waveforms shall be oscillating signals at a frequency that
                   produces a desired number of pulses that can be counted by the ICD breadboard.
                   The number of pulses generated shall be at least the number of pulses specified for
                   output.
3.28.3.          Commands
        The Digital Activity Sensor interface shall support commands in addition to those specified for all
        functional interfaces in the common requirements section.

3.28.3.1.   Stage Activity Output
        DAS_25:    The Stage Activity Output command tells the interface to produce an output signal
                   based on the following parameters.
            1.    pre-waveform delay: Specifies a delay in milliseconds to wait before starting the output.
                  Valid range is between 10 and 9999999 ms.
            2.    frequency: Specifies the frequency of the oscillating output. Valid range is between 1
                  and 255 Hz.
            3.    number of intervals: Specifies the minimum number of pulses to generate.
                  Valid range is between 0 and 2,147,483,647.
            4.    startup mode: Dictates the method of operating synchronization. Choices are:
                  1.   now: change immediately from the current mode.
                  2.   next: change following the next pulse.
                  3.   wait: change after the current waveform finishes.

        DAS_27:    For any startup mode specified by the Stage Activity Output command, the DAS
                   interface should switch to this new interval definition within 1 ms of terminating the
                   previous interval definition.
        DAS_29:    If the number of intervals specified by the Stage Activity Output command is 0, the
                   waveform shall repeat until another command (Stop Current Output or Stop All Output)
                   stops the output or until the interface is reset by a Finish Test or an Abort Test
                   command.
        DAS_35:    Up to 150 stage buffers shall be queueable via startup mode 3 of the Stage Activity
                   Output command.
        DAS_37:    While the stage buffer already holds an operation waiting via the “next” startup mode,
                   the Stage Activity Output command shall return an operating error indication for
                   subsequent “next” mode requests.
        DAS_39:    The previous staged operation shall always take precedence for the Stage Activity
                   Output command.
        DAS_41:    The Stage Activity Output command shall return a success or failure indication within
                   15 ms.
3.28.3.2.   Stop Current Output



       PN# TBD            St. Jude Medical CRMD Confidential         October 16, 2011          Page 46
                   St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


      Additional information for the Stop Current Output command is provided here, supplementing the
      requirements provided in the Common Requirements section.

      DAS_43:       The Stop Current Output command shall terminate the output channel, returning it to a
                    digital zero value within 10 ms.




3.28.4.          Data
      DAS_60: The DAS interface shall collect the following data each time a waveform is started.
      field name           type               description
      system timetag       unsigned long Time the waveform output began.
      operation            enumerated         STAGE_ACTIVITY START_ACTIVITY, or
                                              DONE_ACTIVITY,
      pre-waveform delay   unsigned long Delay before start of waveform
                                              (STAGE_ACTIVITY and START_ACTIVITY
                                              only)
      frequency            float              Output frequency in Hz (STAGE_ACTIVITY
                                              and START_ACTIVITY only).
      requested pulses     unsigned long Minimum number of pulses to generate
                                              (STAGE_ACTIVITY and START_ACTIVITY
                                              only).
      startup mode         enumerated         NOW(0), NEXT(1), WAIT(2)
                                              (STAGE_ACTIVITY only)



      DAS_61:    The DAS interface shall collect the following data each time a Stop Current Output,
                 Stop All Output, or Wait For Idle command is executed.
      field name               type               description
      system timetag           unsigned long Time the waveform output began.
      Operation                enumerated         STOP_CURRENT_ACTIVITY,
                                                  STOP_ALL_ACTIVITY,
                                                  WAIT_FOR_IDLE

3.28.5.          Performance and Timing
      DAS_63:       Output frequency shall be within 0.3Hz of the requested frequency.
3.28.6.          Constraints
          The DAS interface cannot recognize any “happenings”.




      PN# TBD             St. Jude Medical CRMD Confidential       October 16, 2011       Page 47
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.29. Clip File Player
        The Clip File Player is an analog playback system for EGM waveforms. It provides a multi-channel
        analog voltage output to the device. The Clip File Player receives its digital data from a Clip file.
        The digital data is played out to an external amplifier/attenuater which supplies an analog
        representation of the EGM waveforms.

        The Clip File Player is an open loop play back system with the ability to preload a list of Clip files
        and play back the selections. The Clip File Player uses Clip files (the kind that are created by the
        EGM Tool Set Editor).

        CFP_10:       The Neutrino EMT+ shall be able to start and terminate Clip File Player output in
                      response to a telemetry message, or other time tagged event. The flexibility to meet
                      this requirement is provided by this interface in coordination with the Test Controller
                      interface.
3.29.1.          Inputs
        There are no inputs into the Clip File Player interface.
3.29.2.          Outputs
        CFP_20:       The Clip File Player shall output analog data to the Neutrino ventricular sense
                      (VSENSE) channel, as provided in the Clip file digital EGM waveform data source.
        CFP_21:       The Clip File Player shall output analog data to the Neutrino atrial sense (ASENSE)
                      channel, as provided in the Clip file digital EGM waveform data source.
3.29.3.          Commands
        The Clip File Player interface shall support commands in addition to those specified for all
        functional interfaces in the common requirements section.

3.29.3.1.    Stage Waveform Output
        CFP_22:    The Stage Waveform Output command tells the CFP interface to prepare for
                   waveform output, based on the following parameters.
        1. Pre-waveform delay: Specifies a delay in milliseconds to wait in each interval before starting
           the output waveform.
           Valid range is between 10 and 9999999 ms.
        2. startup mode: Dictates the method of operating synchronization. Choices are:
                 1.     now: change immediately from the current mode
                 2.     next interval: change at the end of the current interval
                 3.     wait: change at the end of the last interval, when the current mode finishes

        CFP_23:       For any startup mode specified by the Stage Waveform Output command, the Clip File
                      Player interface shall switch to this new interval definition within 100 ms of terminating
                      the previous interval definition.
        CFP_24:       The CFP interface shall be able to queue up to 150 stage buffers via the “wait” startup
                      mode (3).
        Note that multiple stage buffers may refer to a single arbitrary waveform. Only one stage buffer is
        required via the “next” startup mode (2).




       PN# TBD               St. Jude Medical CRMD Confidential        October 16, 2011        Page 48
          St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


CFP_25:   While the CFP stage buffer already holds an operation waiting via the “next” startup
          mode (2), the Stage Waveform Output command shall return an operating error
          indication for subsequent “next” mode (2) requests.
CFP_26:   The CFP Stage Waveform Output command shall return a success or failure
          indication within 20 ms.




PN# TBD         St. Jude Medical CRMD Confidential       October 16, 2011        Page 49
                   St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.29.3.2.    Load Waveform Output
        CFP_30:     The Load Waveform Output command tells the interface to load a waveform, based
                    on the following parameters.
        1. Clip filename: Valid *.clp Clip File (with fully qualified pathname).
            Clip File Player output shall accept any *.clp file produced by the EGM Tool Set Editor as a
            multi-channel digital EGM waveform data source.
        3. Frequency Amplification Factor: Specifies a value to manipulate the output frequency.
        4. Atrial sense (ASENSE) channel label: Specifies the channel Label from the source Clip file.
        5. Atrial sense (ASENSE) external attenuation value.
        6. Atrial sense (ASENSE) volt/bit: Specifies the channel volt/bit value, will use the value from the
           source Clip file as the default.
        7. Atrial sense (ASENSE) offset: Specifies the channel digital offset value.
        8. Ventricular sense (VSENSE) channel label: Specifies the channel Label from the source Clip
           file.
        9. Ventricular sense (VSENSE) external attenuation value.
        10. Ventricular sense (VSENSE) volt/bit: Specifies the channel volt/bit value, will use the value
            from the source Clip file as the default.
        11. Ventricular sense (VSENSE) offset: Specifies the channel digital offset value.

        One of the following parameter sets are used to determine the section of the Clip File that is used:

        12. Load from Annotation: Set the start and end times - Given a Channel Label, Annotation Text,
            and Annotation occurrence, as input data.
                        OR
        13. Start Time: The start time in the clip to begin playback.
        14. End Time: The end time in the clip to stop playback.




       PN# TBD            St. Jude Medical CRMD Confidential        October 16, 2011         Page 50
                  St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


        CFP_31:   The CFP interface shall provide a resource to manipulate the amplitude and the
                  sampling frequency of an EGM waveform. The amplitude manipulation will be
                  provided on a per channel basis. The system shall provide control over the following
                  variables from Figure 3.1 to manipulate the amplitude of the output signal: The system
                  will provide manual override for the values of Vt, Go and A2, and an automatic
                  calculation for the values of Fd and Vref.

                  Vt Can be changed using the channel volt/bit value to over ride the actual value stored
                  in the clip file.
                  Go Can be changed using the channel digital offset value to provide an artificial offset
                  to the data.
                  A2 Shall be set using the external attenuation value for the given channel to provide the
                  actual hardware attenuation used to replicate the original Vt (Please note, this value
                  will be calculated by the sever if an invalid value is used).
        CFP_32:   The CFP interface shall provide the ability to load a section of a Clip (or a Track) for
                                                       th
                  playback given a channel label, the n occurrence of a Rhythm or Range annotation in
                  the channel, and the text of the annotation used to encompass the section of Clip to
                  load.
        CFP_33:   The user shall be able to load (from Clip files) up to 100 arbitrary waveforms per test
                  into the CFP interface. The system will provide the ability to map the channels from the
                  clip file to the DAC output channels based on the channel label from the Clip file.
        CFP_34:   The CFP interface shall provide a resource to manipulate the sampling frequency of
                  an EGM waveform. The “Frequency Amplification Factor” will use a Default of 1.0 and
                  support a Range of 0.5  x.x  2.0. Required support for this parameter includes 0.5,
                  1.0, 2.0 exclusively.
        CFP_36:   The Clip File Player waveform output shall return to an analog zero value on the last
                  data point of each waveform.
        CFP_38:   The Clip File Player shall provide the ability to have an external indication at the start
                  of each new playback of a Track.
3.29.3.3.   Stop Current Output
        Additional information for the Stop Current Output command is provided here, supplementing the
        requirements provided in the Common Requirements section.

        CFP_40:   The Stop Current Output command shall terminate output to the CFP output channel,
                  returning it to an analog zero value within 20 ms.
3.29.3.4.   Stop All Output
        Additional information for the Stop All Output command is provided here, supplementing the
        requirements provided in the Common Requirements section.

        CFP_50:   The Stop All Output command shall terminate output to the CFP output channel,
                  returning it to an analog zero value within 20 ms.




       PN# TBD           St. Jude Medical CRMD Confidential         October 16, 2011          Page 51
                  St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.29.4.         Data
      CFP_60:     The Clip File Player interface shall collect the following data each time a waveform is
                  started or staged.
      Field name                 Type              Description
      System timetag             Unsigned long Time the waveform output began.
      Operation                  Enumerated        STAGE_WAVEFORM or
                                                   PLAY_WAVEFORM
      pre-waveform delay         Unsigned long Delay before start of waveform
      Waveform identifier        Unsigned long The requested waveform identifier.
      Startup mode               Unsigned long STAGE_WAVEFORM only: The startup
                                                   mode for the waveform: NOW, NEXT, or
                                                   WAIT
      Start Offset               Unsigned long PLAY_WAVEFORM only: Start file offset for
                                                   the waveform being played.
      End Offset                 unsigned long PLAY_WAVEFORM only: End file offset for
                                                   the waveform being played.


      CFP_61:     The Clip File Player interface shall collect the following data each time a waveform is
                  loaded from disk.
      Field name                 type              Description
      System timetag             unsigned long Time the operation began.
      Operation                  enumerated        LOAD_WAVEFORM or
                                                   LOAD_WAVEFORM_FROM_ANN
      Waveform identifier        unsigned long The requested waveform identifier.
      file name                  String            Name of the file used
      Atrial Sense Channel       String            Channel Label, ext Atten , [volt/bit], [offset]
      Ventricular Sense          String            Channel Label, ext Atten , [volt/bit], [offset]
      Channel
      Frequency Amp Factor Double                  Default 1.0 Range 0.5  x.x  2.0
      Start Time                 Double            LOAD_ WAVEFORM only:
                                                   Default 0.0
                                                   Range 0.0  Start Time
      End Time                   Double            LOAD_ WAVEFORM only:
                                                   Default End Of .File
                                                   Range Start Time<End Time End .Of .File.
      Load From Annotation String                  LOAD_NAMED_WAVEFORM only:
                                                   Channel Label, “Ann Text”, Occurrence


      CFP_62:    The Clip File Player interface shall collect the following data each time a Stop Current
                 Output, Stop All Output, or Wait For Idle command is executed.
      Field name                Type              Description
      System timetag            Unsigned long Time the operation began.
      Operation                 Enumerated        STOP_CURRENT_OUTPUT,
                                                  STOP_ALL_OUTPUT, or
                                                  WAIT_FOR_IDLE




      PN# TBD           St. Jude Medical CRMD Confidential        October 16, 2011         Page 52
                   St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.29.5.          Performance and Timing
       CFP_71:     The analog output signal shall be an accurate reproduction of the digital data source to
                   within 5% of the expected values.
3.29.6.          Constraints
      The Clip File Player cannot coexist with the Heart Simulator. The cables used to supply the
       VSENSE and ASENSE shall be manually changed between the Heart Simulator and the Clip File
       Player.

      DAC resolution shall be at least 7 bit, but need not exceed 12 bit resolution.

      Update Frequency. DAC update frequency will be based on the sample rate of the Clip file
       “source samples per second” (the limits of this variable are 250 samples/second/channel up to
       1000 samples/second/channel).

3.30. Test Controller
       The Test Controller interface is an exception in that it has no direct relationships with the ICD.
       The Test Controller interface satisfies requirements for the supervision of activities and has
       numerous links to the Engineering Mode Tester user interface. For the Neutrino EMT+, the Test
       Controller interface serves as the system "master" with the other functional interfaces serving as
       "slaves" to the Test Controller. In all cases, commands received by the other functional interfaces
       are issued from the Test Controller interface.
3.30.1.          Time Synchronization
       TST_03:     The Test Controller shall provide a system time base to be used within the entire
                   system that is synchronized across all functional interfaces.
       The synchronization is important so that time stamps acquired in different functional interfaces
       can be compared to each other.

       TST_05:     The system time base shall be reset to time 0 when each test is started.
       (The system time base works like a synchronized stop watch for each test.)

       TST_07:     A time of day clock is required to provide an external timestamp at the start of each
                   test. The time of day clock shall provide the current year, month, day, hour, minute,
                   and second.
       This external timestamp is only needed to distinguish between different "runs" of the same test
       specification. There is no requirement to synchronize the system time base with the time of day.

       TST_09:
       The system shall be able to synchronize the time of day clocks on all PCs on startup and on
       demand.
3.30.2.          Error Handling
       Error handling is distributed through the Neutrino EMT+ system. The portion of error handling that
       the Test Controller shall perform is described in this section.

       Script and C++ based tests may catch errors at different times. (e.g. Scripts catch many errors
       when the interpreter parses the script at runtime, whereas many C++ errors are detected at
       compile time.) These requirements state that errors shall be caught, but allow latitude in the
       mechanism for catching the errors. It is desirable to catch errors as early as possible.



       PN# TBD           St. Jude Medical CRMD Confidential         October 16, 2011       Page 53
                   St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


3.30.2.1.     Data Range Errors
        TST_15:     Many commands defined in this FRS include parameters that shall fall within a fixed
                    range. The Test Controller shall query the appropriate interface for each command to
                    check that parameters are in range.
        In script mode, parameters that fall outside this range shall be detected as errors before the
        system attempts to run the test. It is allowable to detect this class of error at run time in C++
        mode.

        Individual data range requirements are specified in the Commands subsection for each functional
        interface.

3.30.2.2.     Run Time Errors
        TST_17:     The Test Controller shall acknowledge any reported run time error by aborting the
                    associated test. There is no requirement for "retry strategies" or non-fatal errors.
        TST_19:     When a test is aborted, data already collected prior to the failure shall be preserved to
                    support diagnosis of the failure.

3.30.2.2.1.      Hardware Errors
        TST_21:     The Test Controller interface shall detect and report detectable hardware errors.

3.30.2.2.2.      Timeout Errors
        TST_23:     Failure to respond within the maximum response time for each command (including
                    the special commands such as Prepare For Test) shall be recognized as a timeout
                    error by the Test Controller interface.
        The Test Controller does not need to determine the reason for the timeout (e.g. disabled
        hardware, communication error).
3.30.3.          Supervision
        TST_25:     In its supervisor role during the test, the Test Controller shall be able to interrupt a test
                    in progress. It shall support the user interface requirement to abort a test and return
                    all functional interfaces to their idle state.
3.30.4.          Inputs
        From the Test Controller's point of view, test specifications are inputs to the high level supervisory
        process.

        The ability to redefine some data referenced by a test is a very valuable attribute for the user
        interface, promoting the reuse of test specifications as "templates" that can serve different needs
        depending on the applied data. This preference favors a design that supports run time binding for
        some variables used in a test specification. For example, a test designed to confirm Tach A
        detection time might also be appropriate for Tach B and Fib detection measurements. Suppose
        the only difference between these tests is the interval specification given to the HS interface to
        stimulate one of the three diagnoses. If the user interface provides a mechanism to pass data
        (the interval length) to the test specification at the time of invocation, these three tests will only
        differ in the parameter value used to run the single specification.

        Values to be used for the initialization of variables at run time are also inputs to the Test
        Controller's supervisory process.




       PN# TBD             St. Jude Medical CRMD Confidential          October 16, 2011          Page 54
                      St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


        TST_29:       Test specifications shall originate from the Test Controller interface.
        Commands may then be directed to the other functional interfaces as dictated by the test design.
        This "single source" requirement is important both for the validation and the maintenance of test
        specifications within the system.

        TST_31:       The Test Controller interface shall provide the following data to every functional
                      interface for its associated log files.
            1.    associated test name

            2.    date and time the test was run

        TST_33:       At the end of a test run, the Test Controller shall collect all log information from all
                      functional interfaces and merge the data into a single log file. The user-generated log
                      data shall be placed in a separate file.
        TST_35:       Test specifications shall be represented in either an interpreted "script language,"
                      patterned after C language syntax, or in a C++ Application Programming Interface
                      (API) that can be linked using a standard linker.
        TST_37:       The Test Controller shall process test specifications sequentially, proceeding only after
                      responses have been returned for each in-progress command.
        TST_39:       The Neutrino EMT+ shall recover to an idle state within 60 seconds of test interruption.
3.30.4.1.        Script Language
        TST_45:       The script language shall allow for comments embedded in the scripts.
        TST_47:       The script language shall support direct access to all functional interface commands
                      defined in this FRS, with strict type checking and range checking for all command
                      parameters.
        TST_49:       The script language shall support variables for assignment, evaluation, binary math
                      operations, and same-type comparison in expressions.
        TST_51:       The script language shall support selective execution based on evaluation of
                      expressions in an if - then - else construct.
        TST_53:       The script language shall support iterative execution based on evaluation of
                      expressions in a while - do construct.
        TST_55:       The script language shall support function calls to encourage code reuse and
                      structure.



3.30.4.2.        C++ API
        TST_61:       The C++ API shall be built using an industry standard compiler and linker. These tools
                      shall be able to create applications suitable for the target environment.
        TST_63:       The C++ API shall provide entry points which allow control of the Test Controller and
                      each functional interface.
        Ideally, these entry points will be based on suitable class abstractions.




       PN# TBD               St. Jude Medical CRMD Confidential        October 16, 2011         Page 55
                       St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


        TST_65:        The C++ API shall provide standard header files that users can use to compile their
                       test code.
        TST_67:        The C++ API shall provide libraries (e.g. linkable libraries or DLL’s) that can be linked
                       to the user’s objects to create executables.


3.30.5.             Outputs
        From the Test Controller's point of view, all data resulting from a test are outputs from the high
        level supervisory process. These outputs are in turn reduced to even higher level outputs by
        further evaluation.

        TST_69:        All results created by a test shall be uniquely identified to distinguish different runs of
                       that test (or other tests) from each other.
        TST_71:        The Test Controller interface shall gather the results of each test together in a single
                       location during execution of the Finish Test command.
        TST_73:        The requirement to collect test data includes a history of all commands directed to
                       each interface. Command history data will only be used to debug tests; they will not
                       be needed to validate ICD behavior once a test is "working." The following items shall
                       be collected each time a command is performed.
            1.    command ID: Identifies the command that was received.

            2.    parameters: A text string copy of the command’s parameters, if any. Its length shall not
                  exceed 255 characters.
3.30.6.             Commands
3.30.6.1.        Wait Until Time
        TST_75:        The Wait Until Time command shall force the Test Controller to suspend execution
                       until the system time base is greater than or equal to a specified value. One
                       parameter is required.
            1.    target time: Relative clock time to match or exceed before returning. This target value is
                  relative to time = 0 at the start of the test. Valid values shall be between 1 and
                  2,147,483,647 ms.

        TST_77:        The Test Controller interface shall provide range checking for allowable parameter
                       ranges for the Wait Until Time command.
        TST_79:        The user interface requirement to interrupt a test from within the test execution
                       environment shall still be met during the wait started by the Wait Until Time command.
        TST_81:        A successful indication shall be returned from the Wait Until Time command to the
                       supervisory process if the specified time has already passed.
3.30.6.2.        Delay For Time
        TST_83:
        The Delay For Time command forces the Test Controller interface to suspend execution for an
        interval relative to the current system time. One parameter is required

            1.    delay time: Number of ms to delay before returning. Valid values shall be between 1 and
                  2,147,483,647 ms.




       PN# TBD                St. Jude Medical CRMD Confidential          October 16, 2011         Page 56
                       St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


        TST_85:        The Test Controller interface shall provide range checking for allowable parameter
                       ranges for the Delay For Time command.
        TST_87:        The user interface requirement to interrupt a test from within the test execution
                       environment shall still be met during the specified delay started by the Delay For Time
                       command.
3.30.6.3.        Log
        TST_89:        The Log command directs the Test Controller interface to copy the specified text into
                       the primary log file along with one variable field. Two parameters are required
            1.    log information: String to be copied into the log file. Special characters in the string allow
                  substitution of current variable values.

            2.    secondary information: String to be substituted where special characters are in the first
                  string.
3.30.7.            Data

        TST_92:        A Test Controller log file shall be created on the Test Controller for each test.
        TST_93:        The following log information shall be recorded at the beginning of the Test Controller
                       log file.

        field name                    Type             Description
        test name                     String           Test name as declared in the script/program.
                                                       (maximum 80 characters)
        test ID                       short            Arbitrary number set by user (4 hex digits)

        date                          mm/dd/yyyy       Date of the test run.
        Time                          Hh:mm:ss         Time of the test run.
        TST_95:        The following log information shall be recorded for each command executed by the
                       Test Controller, in the Test Controller log file.

        field name                    Type             Description
        system timetag                Unsigned         System time when a procedure call was
                                      long             made.
        procedure name                String           Name of the procedure being called.
                                                       (maximum 80 characters)
         argument #1 *             ?                 ?
         argument #2               ?                 ?
         argument #3               ?                 ?
         argument #4               ?                 ?
         argument #5               ?                 ?
       *
         The presence (and type) of this and all following fields depends on which procedure generated
       the record. “?” refers to arbitrary parameters specific to each command.




       PN# TBD                St. Jude Medical CRMD Confidential         October 16, 2011         Page 57
                   St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


       TST_97:     The following information shall be recorded for “argument #1” (per TST_95), within the
                   Test Controller log file, when the Log command is executed by the Test Controller.
       Type             Description
       String           String passed to the Log( ) call in the script.
                        (e.g. “rep #%ld”)

3.30.8.          Performance and Timing
       The Test Controller interface shall support the timing requirements imposed on other functional
       interfaces during a test. The level of this support depends on the design architecture. It will be
       critical because a strict "master/slave" implementation is dictated.

       TST_99:     The Test Controller interface should begin running a test within 10 seconds of the user
                   starting that test.
       TST_101: The system time base shall provide 1 ms resolution for all functional interfaces.
       (Any specific requirements for finer granularity are addressed at the functional interface level.)

       TST_103: The time of day clock shall be as accurate to within 0.1% of a recognized time
                standard.
3.30.9.          Dependencies
       TST_109: The Test Controller shall have no specific dependencies on other components of the
                Neutrino EMT. It shall be able to communicate with the user even if all other functional
                interfaces are off-line.

4. Performance Requirements
4.1.   Overview
       This section should specify both the static and the dynamic numerical requirements placed on the
       system or on human interaction with the system, as a whole.

       It is a goal to achieve the same level of repeatability achieved in the Scout EMT. Repeatability in
       the Scout EMT was on the order of 1 ms.
4.2.   Requirements
       PER_03:     The Neutrino EMT+ shall be able to accurately track time. The smallest increment of
                   time reportable shall be 1 ms or less.
       PER_05:     The largest span of time measurable shall be at least 24 hours.
       PER_06:     The timebase shall not overflow in less than 24 hours.
       PER_09:     The Neutrino EMT+ shall meet all interdependency criteria of its interfaces.
                   Performance and timing constraints specific to one functional interface are discussed
                   in the applicable interface subsection. In general, a given interface shall be able to
                   produce a desired output event within 10 ms of a recognized happening on any
                   interface.
       A simple example might be to produce a Digital Output (DO) signal in response to a pulse peak
       generated by the Heart Simulator (HS) interface that is detected by the Digital Inputs (DI)
       interface. This FRS dictates a corresponding chain of events:

          1. Test Controller: Specify a happening within the DI interface to look for the digital signal
             corresponding to the peak to be generated by the HS interface.

          2. HS: Generate a waveform

       PN# TBD            St. Jude Medical CRMD Confidential        October 16, 2011         Page 58
                  St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


        3. Test Controller: Wait for notification of the DI happening.

        4. DI: Recognize the happening and collect a data record.

        5. DI: Notify the Test Controller of the happening.

        6. Test Controller: Receive notification of the happening.

        7. Test Controller: Request a DO command.

        8. Digital Outputs: Twiddle a bit and collect a data record.

       This 10 ms performance requirement assures that the time difference between the data collected
       in step 5 and the data collected in step 8 will be no greater than 10 ms. In addition, happenings
       shall be recognized within 1 ms and the Test Controller interface shall receive notification within
       an additional 5 ms.

       PER_11:    The Neutrino EMT+ system shall be able to generate sequential output events from
                  different functional interfaces no more than 10 ms after completion of the previous
                  event.
       Tests that require a response time across interfaces faster than 10 ms are not within the Neutrino
       EMT+ scope. Some of these high speed test requirements might be met by routing event-driven
       signals from interface outputs directly to "external trigger sources" on interface inputs. The
       inclusion of such capabilities is a desirable design attribute, but not a requirement.

4.3.   Dependencies
       In some specific cases, noted within the individual functional interface sections, the 10 ms
       response time requirement is relaxed. Where not specifically excepted, the 10 ms performance
       requirement applies.
       Real time data collection may make it difficult to achieve some performance targets. Where this
       is the case, the implementation should be scaled back or optimized to minimize any effect on
       performance. The performance requirements take higher priority.


5. External Interface Requirements
5.1. Hardware Interface
5.1.1. Overview
       The hardware interface is defined as the components of the system that connect the input/output
       channels of the Neutrino EMT+ computers to the breadboard ICD.




       PN# TBD           St. Jude Medical CRMD Confidential       October 16, 2011        Page 59
               St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


5.1.2. Requirements
     HW_03:     Full isolation of all signals shall be provided.
     HW_05:     The Interface Box Reset Digital Output signal shall produce suitable high and low
                voltages levels to provide the ability to reset the Neutrino EMT+ Interface Box.
     HW_06:     When the Test Enable Digital Output signal is active, a voltage level compatible with
                the Neutrino breadboard’s Test Enable input shall be placed on the line.
     HW_07:     The Magnet Reed Switch Digital Output signal shall produce an appropriate signal to
                close or open the breadboard reed switch or equivalent circuit.
     HW_09:     The Safe/Enable Digital Output signal shall drain the charge on the defib output
                capacitor when Safe is requested.
     HW_11:     When the Logic Analyzer Trigger Digital Output signal is active, a voltage level suitable
                for triggering the logic analyzer shall be placed on the line.
     HW_13:     A Digital Output signal shall be provided that controls the chart/recorder start/stop line.
     HW_14:     A Digital Output signal shall be provided that controls the chart/recorder marker line.
     HW_15:     A Digital Output signal shall be provided that controls the network switch between the
                Neutrino EMT+ LAN and the external St Jude network.
     HW_17:     The 64 Digital Input lines shall be conditioned to be properly read by the Digital Inputs
                hardware.
     HW_41:     A standard wand (Model 3530 or equivalent), a DTM box ("Data Telemetry Module
                HWT 7048") and a serial link (between the DTM box and the EP computer) shall be
                provided for the EP interface.
     HW_45:     A serial link shall be provided to support communication to and from the BAR.
     HW_49:     The BAR shall be grounded along with the rest of the Neutrino EMT+ system.
     HW_51:     The Neutrino EMT+ shall provide a constant output signal to the BAR indicating that
                the BAR is to be controlled by the Neutrino EMT+.
     This signal will be recognized by the BAR whenever the proper wires are connected.

     HW_53:     Data transfer from the DDP to the device shall be via hardware handshake.
     Hardware synchronization avoids the need to depend on software to synchronize with the device
     micro bus.




     PN# TBD           St. Jude Medical CRMD Confidential          October 16, 2011        Page 60
                  St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


      HW_61:      To distinguish between intentionally ignoring the output stream and missing an update
                  cycle during waveform generation, some additional DDP logic is needed. An extra
                  output line from the PC to the breadboard interface hardware that indicates when
                  waveform output is in progress shall be provided.
      HW_67:      Logic shall be provided in the custom DDP interface hardware to set the error status
                  line if a late acknowledge is sent from the DDP hardware, but only when the waveform
                  output line is active.
      HW_69:      An extra input line back from the breadboard DDP interface to the PC that indicates
                  when a handshake error has occurred shall be provided. This error line shall be reset
                  automatically by firmware in the DDP at the start of each waveform (on the rising edge
                  of the waveform output signal).
      HW_71:      A TTL output signal shall be provided for generation of the DAS signal.
      HW_79:      The CFP hardware shall provide up to two CFP analog output signals available from a
                  breakout block.
      HW_81:      The CFP hardware shall provide a measured output of 2.5mv.
5.1.3. Operation
      The hardware interface consists of an interface box to connect and condition breadboard ICD
      signals to the various input/output interfaces of the Neutrino EMT+.
5.1.4. Dependencies
      It is desirable to reuse hardware created for the Scout EMT where appropriate.

5.2. User Interface
5.2.1. Overview
      The User Interface (UI) provides a simple method for controlling the Neutrino EMT+. Because
      most of the control of the system occurs within the script or C++ program, there isn’t a need for an
      elaborate Graphical User Interface (GUI). Some functional interfaces may be implemented with a
      GUI, but there is no global requirement for that.
5.2.2. Requirements
      UI_03:      The UI shall provide a method for starting test execution from the command line.
      Syntax to run the script executable program shall be as follows:
                  python script <script file name>
                  where <script file name> is either a full or relative path to a python script file,
      Syntax of C++ executable programs is not specified because the user shall create executable
      programs by linking with the C++ API library. The user has complete control over the user
      interface in this case.

      UI_05:      The UI shall clearly indicate to the user whether a test passed or failed.
      UI_07:      When a test fails, the UI shall clearly show the error code and a text description of the
                  error.
      The error information should be as understandable as possible. Extra error information can be
      useful.

      UI_09:      The UI shall provide a method for grouping tests together to allow for longer test runs.
      UI_11:      The UI shall provide the ability to redefine data referenced by a test.
      The ability to redefine some data referenced by a test is a very valuable attribute for the user
      interface, promoting the reuse of test specifications as "templates" that can serve different needs

     PN# TBD             St. Jude Medical CRMD Confidential           October 16, 2011         Page 61
           St. Jude Medical CRMD.  Neutrino Engineering Mode Tester Plus FRS.


depending on the applied data. This preference favors a design that supports run time binding for
some variables used in a test specification. For example, a test designed to confirm Tach A
detection time might also be appropriate for Tach B and Fib detection measurements. Suppose
the only difference between these tests is the interval specification given to the HS interface to
stimulate one of the three diagnoses. If the user interface provides a mechanism to pass data
(the interval length) to the test specification at the time of invocation, these three tests will only
differ in the parameter value used to run the single specification.

Values to be used for the initialization of variables at run time are also inputs to the Test
Controller's supervisory process.

UI_13:      The user shall be able to interrupt test execution at any time by pressing one key or
            simultaneous combination of keys.
The exact key combination is not specified, but it should not be too difficult to type.

UI_14:      If the test is being run within a window, closing that window should interrupt test
            execution in the same manner as when the test is interrupted from the keyboard.
UI_16:      Each functional interface shall show on its own local display when it has completed
            initialization.
UI_19:      A method shall be provided to check syntax of script programs without the use of the
            whole Neutrino EMT+ system. Checks provided by the compiler are adequate for C++
            programs.
UI_25:      The Save Logic Analyzer Setup utility shall be provided as a separate executable
            program. This program shall invoke the Save Logic Analyzer Setup command within
            the LAC interface. Syntax shall be as follows:

            hpsave <setup file name>
            where <setup file name> is either a full or relative path to a file.
UI_29:      If a full file path is provided along with the file name to the hpsave utility, the setup file
            is saved in that location.
UI_31:      If a relative file path is provided along with the file name to the hpsave utility, the setup
            file is saved relative to a designated directory on the main drive of the Test Controller.




PN# TBD            St. Jude Medical CRMD Confidential           October 16, 2011          Page 62

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:10/16/2011
language:English
pages:69