PSMFC. G2 Interrogation System Software Requirements Specification PTAGIS. Version 0.1. December 2, Prepared for:

Transcription

1 PSMFC G2 Interrogation System Software Requirements Specification Version 0.1 December 2, 2004 Prepared for: PTAGIS

2 Prepared by Nadia Gruman Software Engineer December 2, 2004 Page 1

3 TABLE OF CONTENTS 1. INTRODUCTION PURPOSE REQUIREMENTS DEFINITIONS, ACRONYMS, AND ABBREVIATIONS REFERENCES OVERVIEW CHANGE LOG SYSTEM GLOSSARY GENERAL SYSTEM DESCRIPTION SYSTEM PURPOSE SYSTEM SCOPE SYSTEM OVERVIEW SYSTEM CONTEXT SYSTEM STATES OPERATIONAL SCENARIOS SXC SYSTEM CAPABILITIES, CONDITIONS, AND CONSTRAINTS SXC SxC component purpose SxC component scope SxC component overview SxC component context SxC component states SxC component constraints SxC component assumptions and dependencies SxC component requirements REL - SYSTEM RELIABILITY SEC - SYSTEM SECURITY SYC - SYSTEM CONFIGURATION DEPLOYMENT SCENARIOS LIST OF FIGURES Figure 1 G2 Interrogation System Physical Layout... 8 Figure 2 G2 Interrogation System Overview... 9 Figure 3 G2 Interrogation System Context Figure 4 G2 SxC Component Overview Figure 5. SxC Component Context Figure 6 SxC Physical Layout LIST OF TABLES Table 1. Readers supported by SxC... 7 December 2, 2004 Page 2

4 PTAGIS MultiMon Performance PSMFC December 2, 2004 Page 3

5 1. INTRODUCTION 1.1 Purpose This document describes requirements of the G2 Interrogation project. The document contains general description of the system and detailed descriptions of each component. The document purpose is to provide the G2 User Committee with the details of functionality and scope to demonstrate that the end solution conforms to the current and future needs of PTAGIS and related community. The document will serve as the base for design documentation for the project, which will include the system implementation details. 1.2 Requirements definitions, acronyms, and abbreviations Constraint A statement that expresses measurable bounds for an element or function of the system. That is, a constraint is a factor that is imposed on the solution by force or compulsion and may limit or modify the design changes. Interrogation Exciting, detecting, and recording of PIT tags. Near-real time Informal term used by the PTAGIS project to mean duration of hours and not days, weeks, or years. Prototype An experimental model, either functional or nonfunctional, of the system or part of the system. A prototype is used to get feedback from users for improving and specifying a complex human interface, for feasibility studies, or for identifying requirements. PSMFC Pacific States Marine Fisheries Commission. PTAGIS PIT Tag Information System program. Separation by code A specialized interrogation procedure used to divert fish marked with a PIT tag. SxC Separation by code. System requirements Requirements describing what the system must do. To be determined. December 2, 2004 Page 4

6 1.3 References 1) G2 Interrogation Project Plan; Version 0.3; John Tenney; ) MultiMon; Sandra L. Downing and Gordon A. Anderson; ) MultiMon Performance; Version 0.1; N. Gruman; Overview This document contains requirements for the G2 Interrogation system. The document contains the following sections: Section 2: System glossary This section clarifies definitions, acronyms, and abbreviations of terms used for describing requirements. Section 3: General system description This section contains a high-level description of the system as a whole. Section 4: Operational scenarios Operational scenarios describe major system states and how the system enters and exits them. Operational scenarios are grouped by component. Section 5: System capabilities, conditions and constraints This section contains system requirements grouped first by component and then by type of requirement. Section 6: Deployment scenarios This section contains descriptions of types of installations of the system and major functions performed depending on the installation type. 1.5 Change log 12/01/2004 NG Created 12/06/2004 NG Added Requirement Description Format section. 12/08/2004 NG Added SxC operational scenarios diagrams. Formatted: Bullets and Numbering Formatted: Indent: Left: 0 pt 2. SYSTEM GLOSSARY Action A protocol associated with a tag and a device, scheduled for execution. Communication A component whose function is to send interrogation and separation data to PTAGIS. Controller December 2, 2004 Page 5

7 A component whose function is to oversee execution of other components of the system and support communication among them. Device priority Property of every device of a monitor which also contains a gate. This property contains the distance from the device to the gate. The shorter the distance, the higher the priority. Gate An appliance, controlled by PLC, directing fish passage. Monitor LUF Lookup file Monitor A collection of devices connected to the system, consisting of one or more readers and a single PLC unit. PLC Programmable logic controller Reader An electronic device decoding tags. Scheduler A component whose function is to schedule automatic functions of the system. Site configuration A site is a physical location of the computer on which G2 Interrogation system is installed. Site configuration contains information about the number and location of devices connected to the system. 3. GENERAL SYSTEM DESCRIPTION 3.1 System purpose The primary purpose of the G2 Interrogation system is to replace working but outdated existing PTAGIS interrogation and separation client software, namely MultiMon and MiniMon. New system strives to achieve the following goals: Collect interrogation data with validity of 100% This goal is achieved when information entering the system is compared to the data exiting the system and no errors are found. Supply interrogation data to PTAGIS in near real-time December 2, 2004 Page 6

8 This goal is achieved when interrogation data is received by PTAGIS according to schedule. Guarantee 99.9% uptime of all system components This goal is achieved when the calculated system downtime does not exceed 0.1% of uptime. Provide SxC efficiency as good or better as MultiMon This goal is achieved when G2 Interrogation system tag code throughput is as good or better as MultiMon s throughput. For more information about MultiMon efficiency, see MultiMon Performance. Interface with Destron G2 readers and all legacy hardware This goal is achieved when new generation Destron G2 readers can be interfaced by the system and the following legacy readers are supported: Table 1. Readers supported by SxC Device Communication protocol Communication interface Firmware version Specifications FS1001 BPA, ASCII Serial 2.11 Multiple Transceiver System FS1001 User Manual; Release 1.0; Destron-Fearing FS1001A BPA, ASCII Serial 3.11 Multiple Transceiver System FS1001A User Manual; Preliminary Release 1.0 (Version 3.8); Destron-Fearing Interface with PTAGIS data management systems This goal is achieved when PTAGIS data management system receives and successfully processes data sent by the G2 Interrogation system. 3.2 System scope G2 Interrogation system is a system supporting interrogation and, optionally, separation by code. The data received is validated by the system. The system is self-auditing and can be configuration and automated using graphical user interface. Interrogation and separation information is sent to PTAGIS automatically or manually. 3.3 System overview December 2, 2004 Page 7

9 Figure 1 G2 Interrogation System Physical Layout. G2 Interrogation system can be installed on any Windows 2000 system or better. () The system can be connected to one or more readers via regular serial port, RocketPort, DeviceMaster, or Ethernet connection. If the optional SxC component is installed (), G2 can also communicate with an unlimited number of PLC units. Communication with PLC units is performed via Ethernet connection. December 2, 2004 Page 8

10 Communication GUI PTAGIS server Recorder Controller Configuration Scheduler SxC Report Reader PLC Figure 2 G2 Interrogation System Overview. The main function of G2 Interrogation system is to receive data from readers, process it, and send processed information to PTAGIS. The system consists of the following components: Communication Communication component s function is to send interrogation and separation data and diagnostics messages, formatted by Recorder, to PTAGIS and receive remote commands such as to upgrade various components. Recorder Recorder creates data files from information it receives from SxC component if it is active or directly from readers if SxC is inactive. Communication component then sends the data to PTAGIS. Scheduler Scheduler is used to automate system tasks, such as to schedule data submissions. The tasks are performed by Controller. SxC December 2, 2004 Page 9

11 SxC receives data from readers, processes it, and sends commands to open or close gates to PLC. Its main function is to divert fish based in its PIT tag. The information created by SxC is then read by Recorder. Report Report component reads the data received from readers and keeps various counters which can be used to generate reports. GUI Graphical user interface component performs presentation function of the system, including local and internet presentations. It includes interfaces for all other components. Configuration Configuration component is used to format configuration information for the rest of the system and validate existing configuration information. Controller Controller allows components communicate with each other; it starts and stops parts of the system, delegates requests and performs upgrades. December 2, 2004 Page 10

12 3.4 System context Figure 3 G2 Interrogation System Context. G2 Interrogation system interfaces the following: Human user G2 system can be controlled manually or automatically. Human users control the system manually remotely or via graphical user interface. There tasks that can performed only manually, such as configuring the system. Readers and PLC G2 communicates with readers and PLC units via serial ports or Ethernet connection. PTAGIS G2 system exchanges data with PTAGIS and receives remote requests. 3.5 System states G2 system can be in one or more of the following states: 1) Being installed 2) Being uninstalled December 2, 2004 Page 11

13 3) Starting 4) Shutting down 5) Communicating with a user 6) Communicating with one or more devices 7) Communicating with PTAGIS 8) Processing data 9) Upgrading one or more components 10) Receiving data 11) Sending data 12) Configuring the system 4. OPERATIONAL SCENARIOS Operational scenarios document the system behavior when presented with specific events. Each distinct interaction event is documented with a separate scenario. Operational scenarios include a description of data flows and the actions of the system and document the exceptions which can arise. The diagrammatic conventions used in operational scenarios are: 1. Data external to the system is shown in ellipses. 2. Control information enters and leaves at the top of each box. 3. Data leaves from the right of each box. 4. Exceptions are shown at the bottom of the box. 5. The name of the next expected event after completion of the scenario is shown in a shaded box. 4.1 Communication component 4.2 Recorder component 4.3 Scheduler component 4.4 SxC component OS.SxC.01 Initialization and connection December 2, 2004 Page 12

14 Valid configuration Valid connection Configuration Initialize subsystems Device configuration Connect to devices Separation OS.SxC.02 Initialization failure Connection failure Notify user and exit Notify user and exit o OS.SxC Initialization sequence SxC is started by the Controller and attempts to load configuration. The following is the initialization sequence: a) Configuration loading b) Protocol configuration loading c) Lookup file loading When started, SxC loads configuration passed to it; if no configuration is passed, the system will start with the last valid configuration. If there is no last valid configuration saved and no configuration passed, the system shall notify the user and exit. If any of the steps if the initialization sequence fail the system notifies the user and exits. o OS.SxC Unsuccessful connection to devices If SxC initialization sequence is successful, the component connects to monitors listed in site configuration. The connection is successful if at least one reader and one PLC are connected in at least one monitor. If the connection is unsuccessful, SxC notifies the user and exits. o OS.SxC Successful connection to devices If SxC initialization sequence is successful, the component connects to monitors listed in site configuration. If the connection is successful (See OS.SxC.02 for definition of successful connection), SxC starts listening for tags. OS.SxC.02 Separation o OS.SxC Search existing actions December 2, 2004 Page 13

15 SxC runs initialization sequence successfully and starts listening. When a tag arrives, SxC searches list of scheduled actions. If no action for the combination of the tag and monitor exists, SxC searches lookup file. o OS.SxC Action exists Tag New monitor priority is higher Monitor Compare priorities Tag Monitor Action Reschedule existing action Action Tag Monitor Action Tag Monitor Action New monitor priority is lower Tag Monitor Action Acknowledgement OS.SxC SxC compares the priority of the monitor on which the tag was read to the priority of existing action. If the priority of the new monitor is higher, existing action is rescheduled. If the new monitor priority is lower, no action is taken. o OS.SxC Search lookup file December 2, 2004 Page 14

16 SxC searches lookup file using the input tag as a key. If the tag is found, the tag class code and monitor name are used to search protocols. If the tag is not found, default protocol, tag, and monitor name used to create a new action. o OS.SxC Search protocols Tag Monitor Protocols Search protocols Protocol is found Tag Monitor Tag class code Protocol Create new action OS.SxC Tag class code Tag Monitor Protocol not found Tag Monitor Protocol Protocols Use default protocol Using monitor name and a tag class code, SxC searches protocols. If a protocol is found, it is used, together with other information, to create a new action. If no protocol is found, default protocol is used to create the action. o OS.SxC Create new action December 2, 2004 Page 15

17 Using the tag, monitor information, protocol, and, optionally, tag class code, SxC creates and schedules a new action. o OS.SxC Acknowledgement SxC notifies the user that an action for a tag, monitor, protocol, and tag class code is scheduled. o OS.SxC Action execution DDS state DDS state is off Action Check DDS state Action Execute action Action Action DDS state is on Action Acknowledgement OS.SxC Action is not executed When the scheduled time elapses, SxC checks current Divert During Sample (DDS) state. If DDS state is off, the action is executed, if DDS state is off, no action is taken. OS.SxC.03 Device messages o OS.SxC Diagnostic message received from a device When SxC receives a diagnostic message from a device, SxC creates an acknowledgement. o OS.SxC Non-fatal error message received from a device. December 2, 2004 Page 16

18 When SxC receives a non-fatal error message from a device and the device can continue communication, SxC creates an acknowledgement and notifies the user. o OS.SxC Fatal error message received from a device. When SxC receives a fatal error message from a device and the device cannot continue communication, SxC creates an acknowledgement and logs the event. The component then invalidates the device and checks its type. If the device is a PLC, the monitor that contained the PLC is invalidated. SxC checks if other monitors are valid. If there are no valid monitors, SxC notifies the user and exits. OS.SxC.04 Configuration upgrade SxC receives an upgrade request form Controller component. SxC validated new configuration. If the configuration is invalid, SxC notifies the user and resumes execution. If the configuration is valid, SxC disconnects from the devices and starts initialization sequence using new configuration. OS.SxC.05 Disconnect and cleanup When SxC receives a request to stop processing and exit, it cancels all pending actions, disconnects from devices, and saves current configuration. 4.5 Report component December 2, 2004 Page 17

19 4.6 GUI component 4.7 Configuration component 4.8 Controller component 5. SYSTEM CAPABILITIES, CONDITIONS, AND CONSTRAINTS 5.1 Requirement description format For full description, traceability, and testability, each requirement description can have one or more of the following attributes: Table 2 Requirement description format Attribute Description Identification A unique id with the following format: <Component abbreviation>.<function>.<sequential #> Source Operational scenario from which derived Priority High, Medium, Low, Postponed, Out Criticality How essential this requirement for the success of the system: High, Medium, Low Type Type Description or example Input Receive or import data Description Rationale Test Dependencies Conflicts History Detailed description What request or problem the implementation of this requirement will solve. How this requirement can be tested. A list of requirements that have dependency on this requirement. What requirements cannot be implemented if this requirement is implemented. Change log. 5.2 Communication component 5.3 Recorder component December 2, 2004 Page 18

20 5.4 Scheduler component 5.5 SxC component SxC component purpose SxC is an optional component of G2 Interrogation system responsible for diversion of PIT tagged fish. It receives tags from readers, looks them up in the lookup file and depending on the result of the search sends a message to PLC SxC component scope SxC component should implement the separation by code functionality of the final G2 system. The following is the list of goals the component tries to achieve: Read tag code information for the following tags: o 400 khz hexadecimal tags o khz ISO full-duplex B hexadecimal tags Control the separation of PIT-tagged fish by applying separation protocols to a set of antennas and fish diversion gates and perform the following separation functions: o Separation of tagged fish from untagged fish. o Separation of desired tagged fish from undesired tagged fish based on individual tag codes or ratio of fish with certain tag codes. Be able to load according to a configuration file. Be able to load a lookup file SxC component overview SxC component will load a configuration file and lookup file, connect to the devices listed in the configuration file and start listening for tags. The configuration file contains locations of other elements, including site configuration, protocols and the lookup file. Site configuration file contains description of device locations and their grouping. Protocols describe actions to be taken when certain tags are read on selected devices. The lookup file contains tags with associated tag class codes. When a tag arrives, the component reads it and searches collection of scheduled actions. If an action for this tag is already scheduled, SxC logic compares priorities of the device associated with the scheduled action and the device on which the tag was presently detected. If the priority of the device associated with the scheduled action is higher, the component acknowledges the detection and returns to listening for new tags. If the priority of the device associated with the scheduled action is lower, the component re-schedules the action, acknowledges the detection, and returns to listening for tags. If no existing action is found, the component searches the lookup file. If the tag is not found, the component assigns default protocol to the action. If the tag is found, the tag class code is retrieved from the file. SxC then searches existing protocols based on the combination of the tag class code the name of the device on which the tag was read. If a protocol for such combination December 2, 2004 Page 19

21 is not found, default protocol is used. If a protocol for such combination is found, the component used the designated protocol. A new action is then created and assigned the values of the tag, tag class code, priority, and protocol. The action is then scheduled to be executed depending on the priority of the device assigned to the action. The component then acknowledges the detection and returns to listening for new tags. The new action executes assigned protocol when the scheduled time elapses. Figure 4 G2 SxC Component Overview SxC component context G2 system consists of a series of components communicating via IPC interface. The components are controlled by the Controller. The Controller starts SxC using a file created by the Configuration component. SxC loads a lookup file, connects to the devices and starts listening. December 2, 2004 Page 20

22 When a tag is detected, SxC performs needed actions according to the algorithm and outputs data in an acknowledgement form. Recorder, which is also started and configured by the Controller, reads the outputted data and stores it in a file. Communication component sends files and other forms of communication to PTAGIS server (). Communication GUI PTAGIS server Recorder Controller Configuration Scheduler SxC Report SxC context Reader PLC Figure 5. SxC Component Context. SxC has the following interfaces: 1) Communication with the Controller. SxC communicates with the Controller directly and via Log subsystem. Controller starts SxC directly by passing configuration file. SxC stores system errors in the Log subsystem. Controller reads error records from the Log subsystem and displays them by communicating with the GUI component. SxC also sends and receives messages to other components via Controller. For example, Configuration component validates configuration files for SxC communicating via Controller. 2) Communication with devices. SxC component communicates with PLC controlling separation gates via serial or Ethernet () protocol. SxC sends commands to PLC and receives diagnostic messages and information about sub-sampling performed by PLC. () In addition, SxC component communicates with readers. December 2, 2004 Page 21

23 5.5.5 SxC component states The system can have the following states: 1) Loading configuration 2) Listening for tags 3) Computing a protocol 4) Executing an action 5) Stopping execution When the system is in loading configuration state or stopping execution, no other states are valid. The system can be in one or more other states SxC component constraints SxC component assumptions and dependencies SxC component requirements SxC component requirements are grouped by functionality SxC.Act Action An action is an association of a protocol, tag, and the device on which the tag was read; it is created when a tag is read and there is no existing action for this tag. The action is scheduled to be executed at the calculated time, when tagged fish approaches the gate. When the time elapses, the protocol assigned to the action is executed. SxC.Act.01 Action priority An action is assigned a time attribute, or priority, when it is created. The time attribute denote a time delay after which the action is executed. This time delay is an attribute of a reader and indicates calculated time a fish needs to travel from the reader to the gate. The time delay also represents reader s priority, where lower value of the delay means higher priority. SxC.Act.02 Action priority change An action is re-scheduled when the time attribute of this action is changed. SxC re-schedules an existing action when the system detects the same tag that the existing action has and the reader on which the tag was detected has a higher priority than the priority of the existing action. In this case, SxC changes time delay of the existing action to match priority of the reader of the new detection. SxC.Act.03 Action execution An action is executed when SxC sends a signal, appropriate to the protocol assigned to the action, to PLC. After an action is executed, it is destroyed. SxC.Act.04 Action creation SxC schedules a new action when a tag is detected and there is no existing action for this tag on this monitor. December 2, 2004 Page 22

24 SxC.Cnf - Configuration SxC.Cnf.01 Configuration validation Source OS.SxC Priority Criticality High Type Input Description SxC component shall be able to request configuration validation from Configuration component. Rationale What request or problem the implementation of this requirement will solve. Test How this requirement can be tested. Dependencies A list of requirements that have dependency on this requirement. Conflicts What requirements cannot be implemented if this requirement is implemented History Change log SxC component shall be able to request configuration validation from Configuration component. SxC.Cnf.02 Configuration update SxC component shall be able to update and reload its configuration upon a request from Controller component. SxC.Cnf.03 Configuration export SxC component shall be able to export current configuration so that it can be used to audit the program and restart the component SxC.Dat - Data SxC.Dat.01 Acknowledgement creation SxC creates an acknowledgement in the following cases: A tag is detected A message is received from a reader A message is received from PLC Acknowledgements are posted so that Recorder and Report can use the data. Note: Data interface is described in SxC.Fee - Feedback SxC.Fee.01 Feedback creation SxC creates notifies users in the following cases: SxC error December 2, 2004 Page 23

25 Device connection attempt Device error (See Rec.02) Configuration update status SxC exit acknowledgement Configuration validation request SxC.Fee.02 Feedback reception SxC receives feedback in the following cases: Configuration update request SxC exit request Configuration validation response SxC.Mai - Maintenance SxC.Mai.01 SxC upgrade SxC shall be able to be stopped and upgraded by the Controller SxC.Per - Performance SxC.Per.01 Diversion SxC shall divert as correctly as MultiMon or better. This can be measured by running MultiMon and SxC side by side and comparing signals to the gates and acknowledged tags. December 2, 2004 Page 24

26 SxC.Phy - Physical Layout Monitor Reader PLC DeviceMaster G2 System SxC Figure 6 SxC Physical Layout. SxC.Phy.01 Layout SxC shall communicate with one or more Monitor units via one or more DeviceMaster units. See the definition of a Monitor in Glossary section. SxC.Phy.02 Basic layout rule SxC will run only if it is able to communicate with at least one valid Monitor units. SxC.Phy.03 Valid Monitor rule A Monitor unit is valid for communication with SxC if it consists of one or more Reader and one PLC SxC.Plc - PLC Communication SxC.Plc.01 Open gate message SxC shall be able to communicate to PLC a command to open the gate. SxC.Plc.02 PLC sampling rate SxC shall be able to request and receive PLC sampling rate and incorporate PLC rate into computation () SxC.Plc.03 PLC error message SxC shall be able to receive and acknowledge an error message from PLC. The message is acknowledged when it is posted to the Data subsystem. SxC.Plc.04 PLC diagnostics message () December 2, 2004 Page 25

27 SxC shall be able to receive and acknowledge a diagnostics message from PLC. Note: PLC communication interface is described in SxC.Pro - Protocol Protocol definition A protocol shall describe a relationship between a tag class and a Monitor on which a tag belonging to this class is detected. Classification of tags is described in System Configuration (Syc.03) section below. Protocol operation A protocol shall include an operation to be performed when a tag of the tag class assigned to the protocol is detected on the Monitor assigned to the protocol. The operation can be described in the following terms: Sampling rate Max number Start date and time End date and time Day of week Max number per day All the terms shall be taken into account when a protocol is executed. SxC.Pro.01 Number of protocols SxC shall include at least one protocol. The number of protocols SxC shall be able to handle depends on the size of the memory of the machine SxC is running on. SxC.Pro.02 Default protocol A protocol can be designated as a default protocol. A default protocol is a protocol which describes a relationship between a Monitor on which it was detected and a tag which does not belong to a known tag class; or a relationship between a Monitor and a known tag class that does not have an operation assigned to it. Only one protocol can be a default protocol. SxC.Pro.03 Sampling rate Sampling rate is a percentage of fish of a certain class to be diverted. Example: 30% sampling rate means to divert a third of all fish that has tags of the class assigned to this protocol and detected on this Monitor. Note: PLC sampling protocol is incorporated into calculations. () SxC.Pro.04 Max number Max number is the number of fish of a certain class to be diverted. Example: 1000 max number means to divert first 1000 of all fish that has tags of the class assigned to this protocol and detected on this Monitor. December 2, 2004 Page 26

28 SxC.Pro.05 Start date and time Start date and time are date and time on which to start execution of the operation. If a tag of this class is detected on this Monitor before this date and time, if the date and time are specified, no operation will be performed. SxC.Pro.06 End date and time End date and time are the date and time on which to stop execution of the operation. If a tag of this class is detected on this Monitor after this date and time, if the date and time are specified, no operation will be performed. SxC.Pro.07 Days of week Days of the week denotes the days on which to execute the operation. If a tag of this class is detected on this Monitor and the day of the week is not one of the days specified, no operation will be performed. If no days of the week are specified, SxC shall assume that the operation is legal on all days of the week. SxC.Pro.08 Max number per day This attributes specifies max number of fish per day for which the operation is to be executed. Example: Max number per day is 8. If a tag of this class is detected on this Monitor and it is the ninth fish that will be diverted using this protocol today, the operation is not executed. If it is the seventh fish that will be diverted using this protocol today, the operation is executed. Note: Protocol configuration format is described in SxC.Rec - Reader Communication SxC.Rec.01 Tag detection SxC shall read tags detected by readers successfully connected to the system. The following tag types shall be accepted: 400 khz hexadecimal tags khz ISO full-duplex B hexadecimal tags The tags shall be processed by SxC and acknowledged by posting a message to Data subsystem. SxC.Rec.02 Reader error message SxC shall read an error message sent by reader and acknowledge it by posting the message to the Data subsystem and to the Log subsystem. SxC.Rec.03 Reader diagnostics message SxC shall read a reader diagnostics message and acknowledge it by posting the message to the Data subsystem. SxC.Rec.04 Supported readers SxC shall support communication the readers listed in Table 1. December 2, 2004 Page 27

29 SxC.Syc - Configuration SxC configuration includes general system configuration used by this and other components and the part of the general configuration that is used only by SxC. SxC configuration shall be described in a series of configuration files including the following: Protocol configuration Site configuration Lookup file SxC.Syc.01 Protocol configuration Protocol configuration shall contain information for each protocol to be used by the system for diversion. The information for each protocol shall include tag class code, Monitor identification, and protocol operation. SxC.Syc.02 Site configuration Site configuration shall contain information for each Monitor connected to the system. See description of a valid Monitor in Physical Layout (SxC.Phy.03). SxC.Syc.03 Lookup file Lookup file shall contain tags assigned to a tag class and the corresponding tag class code. Note: System configuration are also described in System Configuration section. 5.6 Report component 5.7 GUI component 5.8 Configuration component 5.9 Controller component 5.10 Rel - System Reliability Rel.01 System uptime G2 Interrogation system shall guarantee 99.9% of uptime Sec - System Security Sec.01 System security G2 Interrogation system shall use authentication preferences of the operating system on which it is installed. () December 2, 2004 Page 28

30 5.12 Syc - System Configuration Syc.01 G2 Interrogation system configuration G2 Interrogation system configuration contains general system configuration information used by several or all components of the system and information for each component of the system only used by this component. Syc.02 Devices General system configuration shall include information about devices connected to the system and name these devices. Syc.03 Site information General system configuration shall include the name and type of the site used. See Deployment Scenarios section for the list of site types. Syc.04 User preferences General system configuration shall include user preferences. () 6. DEPLOYMENT SCENARIOS The following is the list of the types of sites and major functionality of the system used by this type: DS.01 Dams with SxC This type of sites will use full system functionality. They can have monitors for SxC or single devices for interrogation. DS.02 Dams without SxC This type of sites will use full system functionality with the exception of SxC component. DS.03 Small-stream interrogation This type of sites will not use SxC functionality. Communication will be limited to sending data to PTAGIS. DS.04 Adult interrogation Adult interrogation sites will not use SxC functionality. Communication will be limited to sending data to PTAGIS. December 2, 2004 Page 29