Air_quality_monitor_SOW.xlsx
XLSX spreadsheet 33 KB Posted
- Solicitation number
- SVM30013Q0008
- Issued by
-
Department of State US Embassy Hanoi
View the file
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
All Requirements
| Ref No | State Department Requirement | Component | Approach (How it accomplishes the Requirement) |
| Basic high-level business requirements | |||
| 101 | System shall, at specified schedule (e.g. hourly), take data readings, error codes, and calibration data from instruments and record data locally | ||
| 102 | System shall aggregate raw data centrally, so that ALL computation and communication shall be performed and managed centrally | ||
| 103 | System shall enable system admins to make configuration changes to publishing channels and content without programming. | ||
| 104 | System shall compose and publish current data, making it available and consumable by third-parties | ||
| 105 | System shall present published information on a state-dept managed website (system is capable of ingesting certain types of data feeds). We may or may not choose to publish in foreign languages, but want the capability to do so. | ||
| 106 | System shall present published information on a aqi-specific public webpage (created by and hosted by vendor) formatted for desktop PC browsers. | ||
| 107 | System shall present published information on a aqi-specific public webpage (created by and hosted by vendor) formatted for mobile devices browsers (i.e. small screens). We may or may not choose to publish in foreign languages, but want the capability to do so. | ||
| 108 | System shall make historical data for selected missions (e.g. non-china) available to general public but restrict availability of historical data for other selected missions to a list of people managed by sys admins. Note: We want system to have capability to provide historical data, but this feature cannot be open to public. | ||
| 109 | System architecture/tech design will put lowest burden possible on IRM staff | ||
| 110 | System shall be capable of adding additional missions (e.g. India, Nepal, etc.) in future (will presumably require ammendment to support contract). Note: may require additional language capability. | ||
| 111 | System shall be capable of adding additional monitoring sites to existing missions in future (will presumably require ammendment to support contract). | ||
| 112 | System shall be capable of adding additional instruments to existing sites in future (will presumably require ammendment to support contract). | ||
| 113 | System shall be capable of adding new types instruments (e.g. add aethalometer) in future at modest cost. | ||
| 114 | AQI system scope of work excludes any work needed for the instruments themselves (system stops at the cable to the instrument) | ||
| 115 | One site may have a secondary/failover instrument present. System needs to record data from secondary and use the data if primary instrument is down. | ||
| 116 | System shall be fully operational within 6 months of contract award. | ||
| 117 | System shall be resistant to outside tampering. Note: this system is a tempting target for mischief. | ||
| 118 | System shall be fault tolerant. Note: system is 24x7 but mission staff is not. |
| Business Assumptions | |
| 119 | System shall accommodate varying timezones and DST (daylight savings time) for missions and sites (and central server). |
| 120 | One monitoring station = one site. For forseeable future, there is no requirement to publish data averaged across geography (i.e. multiple sites). Note: in this respect, ours is a much simpler system than most setups in US. |
| 121 | System may need capability to calculate values differently for one site vs. another. |
| 122 | System will compose and publish messaging consistently across each mission. Composition and publishing may differ from mission to mission. |
| 123 | Monitoring sites lack support personnel, so system must support remote administration (for changes, updates, debugging, repair). |
| 124 | System shall require no manual intervention during data processing (e.g. for assessing outliers, etc.). Note: our understanding is that EPA's AIRNOW system provides this capability (and we do not need/want this feature). |
| Technical Assumptions | |
| 125 | System will use RSS feed to make data consumable by third-parties Note: see #104 above |
| 126 | System will publish to Twitter sites (in addition to other channels) |
| 127 | PC's at monitoring stations will run basic software from instrument mfr (e.g. Comet, Ecotech), in addition to whatever is required for this system |
| 128 | All communication between site PC's and central server(s) will be encrypted to reduce risk of tampering. |
| 129 | Publishing from central server(s) to the various channels (e.g. Twitter, RSS, websites, etc.) will be performed in secure, tamper-resistant manner. |
| 130 | Missions will provide all site hardware, including monitoring instruments, PC, UPS, cabling, etc. Missions will provide internet connectivity. |
| 131 | Central server will reside in US |
Detailed business requirements:
| At each monitoring station (client) | |
| 201 | System shall collect all NEW data (readings, date/time, error codes) from each instrument on specified schedule (e.g. hourly) and record to local PC. Note: NEW data refers to data not already collected. Unless system is offline for a while, NEW data means 1 hour's worth typically |
| 202 | System shall on specified schedule (e.g. hourly) compare date/time of site PC with date/time of each instrument and if they differ by specified threshold, reset instrument date/time and send an alert to system admins |
| 203 | If connection to internet/tunnel/server is down, site system will continue to record data to local PC |
| 204 | If instrument or PC is powered down (planned or unplanned), system will automatically return to functioning state when power is restored |
| 205 | All communication between site PC's and central server(s) will be encrypted to reduce risk of tampering. |
| 206 | Site system will test, on specified schedule (e.g. hourly), connectivity (and encryption status), and correct if needed (and send alert to admins if not correctable). Note: we recognize that depending on the type of problem, "send alert" might fail also |
| 207 | System shall be capable of adding new types instruments (e.g. add aethalometer) in future at modest cost. |
| 208 | System shall transport data on specified schedule (e.g. hourly) from sites to central server. Note: system shall leave a copy of the raw data on the local site PC. |
| 209 | Data transport mechanism should readily work with addl instruments/parameters. |
| 210 | If bad actor gains physical access to AQI PC (or walks off with encryption keys), system should prevent this person from reading/writing to other AQI PC's or AQI server (to extent possible). |
| 211 | System shall have mechanism for remote administration of software and instrument interface. |
| 212 | After admin makes any configuration changes, system will validate changes and alert admin to any errors. |
| 213 | Because of the very limited resources and because of the tampering risk, system will have only bare minimum of hardware/software installed at monitoring sites. |
| 214 | System will accommodate having two instruments (a "primary" and "secondary") of the same type (e.g. "BAM") at a single site |
| 215 | If system at site has dependency on a commercially purchased encryption tunnel (e.g. VPN), then system at site will also have available a backup/secondary encryption tunnel (VPN). System will automatically switch to backup if primary fails the test (and send an alert to system admins). |
Central system (server)
| 301 | System shall transport all NEW data on specified schedule (e.g. hourly) from sites to central server. Note: system shall leave a copy of the raw data on the local site PC. Note: NEW data refers to data not already collected. Unless system is offline for a while, NEW data means 1 hour's worth typically |
| 302 | System shall on specified schedule (e.g. hourly) compare date/time of server with date/time of each site PC and if they differ by specified threshold, reset site PC date/time and send an alert to sys admins Note: refer to requirement 119 |
| 303 | System shall parse the harvested data and store it centrally (including reading date/time, mission/site/instrument identifier(s), parameter identifier(s), readings/values, error data, etc.) |
| 304 | SEE REQUIREMENT 205 Note: encrypted communication |
| 305 | Central system will test, on specified schedule (e.g. hourly), connectivity (and encryption status) to each site PC, and correct if needed (and send alert to system admins if not correctable). Note: we recognize that depending on the type of problem, "send alert" might fail also |
| 306 | SEE REQUIREMENTS 110,111,112,113 Note: expandability requirements |
| 307 | System shall confirm that the data harvested from each site is in proper format and uncorrupted. If data is corrupt or in bad format, system will send alert to system admins. |
| 308 | If system cannot connect to a monitoring station, system will send alert to sys admin |
| 309 | If data is in bad format or data is unrecognized (e.g. non-numeric) or corrupt, system will email sys admin |
| 310 | System will, on specified schedule (e.g. hourly), evaluate error codes harvested from instruments and take specified action (see "error code Action" below) |
| 311 | System shall, on specified schedule (e.g. hourly), evaluate raw data values for acceptance (see "acceptance check" below) and take specified action if value is outside acceptable range |
| Compute | |
| 401 | System will, on specified schedule (e.g. hourly), compute the specified parameters (listed below) and store them. Note there are small diffs from std EPA computations. Note that "PM2.5 concentration formatted" and "ozone concentration formatted" differ from raw values. |
| 402 | System shall accommodate periodic changes to algorithms (e.g. when EPA changes regulations for AQI computation) |
| 403 | System shall have mechanism to enable ESTH to feed system a set of test data values (to allow for testing and verification of all computations without instrument actually recording the value) |
| 404 | System will use raw data values for computation until specified otherwise. Note: careful about "round" vs "truncate" in algorithms. |
| 405 | System shall use, as the nominal reading date/time, the date/time at the end of the reading interval (unless specified otherwise) Note: EPA systems use start date/time in certain instances and end date/time in others, so need to be careful. |
| 406 | If monitoring site has both a primary and secondary instrument (of same type) and both are online, then system will compare readings from these instruments (see algorithm below), and send an alert if out of range |
| Compose, data-driven | |
| 501 | System will, on specified schedule (e.g. hourly), read a list of composition instructions from a configuration. Each instruction will specify enabled/disabled, frequency, composition type |
| 502 | System will enable system admins to manage the list of composition instructions |
| 503 | Composing instructions set "disabled" will be skipped |
| 504 | Composition Types will be one of the following: See List of Composition Types below. |
| 505 | For each composition type, system shall follow the format/rules below: See List of Composition Types below |
| 507 | Unless noted otherwise, if no data is available for a given time period, then system shall compose using value of "No Data". Note: if part of system is down (e.g. instrument, site PC), then we want to continue to compose and publish "No Data" unless system admin disables composition and/or publishing. |
| Publishing, data-driven | |
| 601 | System will, on specified schedule (e.g. hourly), read a list of publishing instructions from a configuration and perform each. Each instruction will specify enabled/disabled, site, channel, content (composition type) to publish |
| 602 | System will enable system admins to manage the list of publishing instructions |
| 603 | Publishing instructions set to "disabled" will be skipped |
| 604 | Channel will be one of the following: Twitter, Weibo, FTP (to publish RSS, graphs) |
| 605 | For each publishing instruction, system shall apply the channel-specific requirements/rules (as described below). |
| 606 | Unless noted otherwise, system shall publish all "NEW" data. Note: most of the time "NEW" data is simply the data computed for the most recent hour. In the the event that a site is down for a few hours, however, then "NEW" data might include a few hours data. Note: This feature makes the system more robust than the current system, which has "holes" in published data. |
| 607 | System shall log all publishing, so central system maintains a record of all communications made (e.g. list of tweets, RSS updates, SMS alerts, etc.) |
| 608 | Certain publishing channels (e.g. Weibo) may require Chinese-language support for integration (e.g. passing credentials). |
| 609 | System shall provide capability for system admins to publish an ad hoc short message. |
| Requirements for publishing RSS and graphs via FTP channel | |
| 610 | System will publish RSS feeds and graphs to vendor-hosted websites via FTP. Websites will be accessible without need for VPN. |
| 611 | RSS feeds and graphs will be hosted in way that minimizes risk of tampering and blocking |
| 612 | FTP parameters (address, credentials, etc.) will be read from configuration managed by system admins. |
| Requirements for publishing Twitter channel | |
| 613 | System will authenticate to Twitter using Twitter's specified practices (i.e. OAth, certain keys will not be stored in plain text, etc.) |
| 614 | Twitter parameters (e.g. credentials) will be read from configuration managed by system admins |
| 615 | Email account associated with each Twitter account will be non-gov't and not used for any other purpose (to reduce risk) |
| Presentation | |
| 701 | System shall include design and hosting of a vendor-hosted AQI website formatted for mobile phone/smartphone browsers (want to support iPhone, Blackberry, Android, and any other model supported by Vietnamese mobile phone companies). Website will consume the RSS feeds and graphs published by system. |
| 702 | System shall include design and hosting of a vendor-hosted AQI website formatted for desktop PC browsers (e.g. IE, Firefox, Chrome, Safari). Website will consume the RSS feeds and graphs published by system. |
| 703 | AQI websites, whether for desktop pc or mobile phone, will include some static AQI information and links to other online resources. |
| 706 | Vendor will host websites in manner that avoids tampering |
| 707 | Vendor will ensure that websites are not blocked (this may mean moving website occasionally) |
| 708 | AQI website (PC browser version only, not for mobile phones) will offer online reporting tool (see Reports section) for querying historical data and saving to local CSV or XLS format. For certain missions (as configured by sys admin), website will require user to authenticate before accessing the report tool. See Reports section for more info. |
| 709 | AQI websites may not contain ads. |
| 710 | AQI website for mobile device should, by default, show current PM2.5 reading, 24-hr vertical bar graph PM2.5, with ozone reading and graph below, and any additional instrument parameters under that. Site (city) should be user-selectable and "remember" previous setting. |
| 711 | AQI website for PC should, by default, show current PM2.5 reading, 24-hr vertical bar graph PM2.5, ozone reading and graph, and any addl instrument parameters for that site under that. Site (city) should be user-selectable and "remember" previous setting. |
| System administration | |
| 801 | System will have mechanism for remote administration (i.e. remote desktop) into monitoring station PC's by sys admins |
| 802 | System will have mechanism for sys admins to remotely use instrument mfr software (e.g. Comet, Ecotech) to retrieve data for evaluation by sys admin or ESTH |
| 803 | System will provide mechanism for sys admins to configure operating parameters for the system (e.g. for overall system, for each mission, each site, each instrument, instrument types, channel types, RSS parameters, admin list, report access credentials, etc.). |
| 804 | After sys admin makes any configuration changes, system will validate changes and alert admin to any errors |
| 805 | System will provide mechanism for sys admins to manage list of "Mission Admins", who can perform same functions as sys admins, except scope is limited to their assigned Mission. |
| 806 | Sys admins will have to authenticate before gaining access to system. |
| 352 | A special list of "superusers" may perform all system functions including managing list of administrators and other "superusers". |
| 353 | Superusers/administrators will have to authenticate individually in order to use system (however, we do not need integration to AD/single-sign-on). |
| 354 | System shall provide to administrators basic reporting metrics (hits, locations of users IP addresses) for AQI-specific mobile device webpages. Note: this metrics system may be standalone and may leverage tool like google analytics or similar. |
| 9-Reports: Admin Reports | |
| 901 | System shall provide sys admins with a report showing performance metrics for monitoring purposes. This report will include user-specified date range, site availability, numbers of delayed/missed readings, delayed/missed publishing. |
| 902 | System shall provide sys admins with a report showing usage metrics for public websites. This report will include user-specified date range, web site, monitoring site, traffic counts, browser types, etc. |
| 9-Reports: Public Reports Available on AQI Website | |
| 903 | System shall have capability to generate historical data reports from the public website. Depending on mission configuration, site visitors may or may not have to authenticate to access the report. |
| 904 | For historical data report, user will specify date range, mission/site, and parameter(s). Parameter will default to 24-hr average PM2.5. |
| 905 | Historical data report will be exportable/downloadable to CSV format. |
| 906 | For historical data report, sys admins will be able to specify any of the parameters computed by the system, but general users will only be able to choose from a subset of parameters. Sys admins will configure which parameters are available to general users. Note: we'll likely restrict general users to basic few parameters (PM2.5 24-hr avg, ozone 24-hr, etc.), but sys admins need the lot. |
| Hosting/Support/Fault-tolerance Requirements | |
| 1001 | If central system is powered down (planned or unplanned), it will automatically return to functioning state when power is restored |
| 1002 | System will have regular backups |
| 1003 | If central system encounters an error retrieving data, parsing data, computing data, or publishing data, system will log error and send alert to system admins and continue operating |
| 1004 | System will require no more than 30 minutes to read data from instruments, harvest to central server, compute parameters, compose display data, and publish to all channels. |
| 1005 | System will be hosted in US |
| 1007 | Vendor shall provide minimum of 1 year hosting and support after startup that includes any/all changes to ensure continued operation |
| 1008 | During support period, vendor shall provide workarounds/mitigation for problems due to any interference/blocking |
| 1009 | During support period, vendor will provide support through a "duty phone" approach and handle non-urgent issues by email. |
| 1010 | Prior to startup, vendor shall provide training to initial group of sys admins (and mission admins). Training on-site preferred. |
| 1011 | System is property of State Dept. Vendor will provide copy of source code for all central systems software to the State Dept as part of delivery. State Dept may share code with other parties. Note: per E-Diplomacy request |
| Documentation for monitoring stations | |
| 1101 | How to set up software at monitoring station |
| 1102 | How to maintain/administer software at monitoring station |
| 1103 | How to troubleshoot software at monitoring station |
| 1104 | Disaster recovery (hardware failures) at monitoring station |
| 1105 | How to work around blocking and/or tunneling issues (e.g. vpn) at monitoring station |
| 1106 | Copy of source code and installable files for monitoring station software |
| 1107 | How to deploy code update to monitoring stations |
| 1108 | How to reconfigure system when we change ISP's at monitoring station |
| 1108 | How to set up software at central server |
| 1109 | How to maintain/administer software at central server |
| 1108 | How to troubleshoot software at central server |
| 1109 | SOPs for standard admin functions such as adding/removing a mission, adding/removing a site, adding/removing an instrument, etc. Note: user guide for admin functions |
| 1110 | SOPs for issues such as Twitter acct is compromised, website blocked, VPN blocked, etc. |
| 1111 | Disaster recovery (server failure, router failure, etc.) |
| 1112 | How to reconfigure system if we have to move website |
| 1113 | Wiring diagram/schematic for overall system showing all sites and instruments. |
| 1114 | Copy of source code and installable files for central system |
| Hardware requirements | |
| 1201 | System at each monitoring site will operate a HP workstation running Windows 7 |
| 1202 | Instruments at site, initially, will include one or more of the following: BAM 1020 FEM version, EcoTech EC9810 |
Options Options
| Note to bidder: price this option separately | ||
| OPTION A: Email health alerts to subscriber list | ||
| Detailed business requirements: | Comment | |
| 1301 | Vendor will provide a vendor-hosted, public-facing website to enable site visitors (general public) to self-register for AQI email notifications. Website will feature prominent disclaimer regarding use of the service (i.e. intended for use by Americans, etc.) | Note: website must make clear that use is intended for Americans. |
| 1302 | System will prevent automated registrations | Note: use captcha or other scheme to weed out robots |
| 1303 | System will require user to specify notification parameters including email address, monitoring site, AQI threshold, notification schedule, and language option if appropriate (See #1304) | |
| 1304 | System will only make certain languages available for certain sites based on system configuration | |
| 1305 | System will validate email address using verification email (or other equivalent method) | Note: want to reduce risk of someone signing up other people |
| 1306 | System will use a deadband or other means to avoid "nuisance" alerts | Note: if threshold is 200 and AQI fluctuates from 195 to 205 to 195 to 205 all day, nobody wants a dozen email alerts |
| 1307 | System will send an alert email to subscriber list based on the notification parameters specified. Content of the email will be configurable by sys admins, and email will include an unsubscribe link at end of message. | |
| 1308 | System will count bounces and undeliverable messages, but does not need to retry failed sends. | |
| 1309 | System will "unsubscribe" a subscription when user clicks "unsubscribe" link. No verification is necessary. | |
| 1310 | Vendor shall provide 1-year support via email to end users (general public) for this service. Support includes helping users who try to unsubscribe but still receive messages, and those who subscribe but do not receive messages (e.g. spam filters, etc.). | |
| 1311 | Also during the 1-year initial support period, vendor shall ensure that system is capable of delivering emails properly | Note: have to avoid/remedy blocking at great firewall |
| 1312 | System shall provide usage report to sys admins that shows date range, subscriber counts, bounces/delivery failures, and notification parameter selections | Note: so ESTH can analyze what end users are requesting and how much is getting through |
| 1313 | Vendor shall make all reasonable efforts to ensure that emails are not filtered out as spam. | |
| 1314 | System shall automatically remove addresses that fail/bounce consistently for a specified period of time | Note: expunge bad addresses |
File details come from the government source that posted it. Updated .