STANDARD SERVICES END USER TERMS

MANGAN SOFTWARE SOLUTIONS, Inc. SOFTWARE AS A SERVICE (SaaS) STANDARD TERMS

FOR INFORMATION ONLY

© Copyright MSS All rights reserved

Title in and to this document and all information contained herein remains at all times with Mangan Software Solutions, Inc.

  1. DEFINITIONS.

1.1.         “Access Credentials” means any user name, identification number, password, license or security key, security token, PIN or other security code, method, technology or device used, alone or in combination, to verify an individual’s identity and authorization to access and use the Hosted Services

1.2.         “Authorized User” means a specific individual authorized by the PROVIDER to access the Services pursuant to Section 2 and the other terms and conditions of this Agreement, regardless of whether the individual is actively using the Services.

1.3.         “Available” has the meaning set forth in Section 5.1.

1.4.         “Availability Requirement” has the meaning set forth in Section 5.1.

1.5.         “Confidential Information” means information in any form or medium (whether oral, written, electronic or other) that the Disclosing Party considers confidential or proprietary, including information consisting of or relating to the Disclosing Party’s technology, trade secrets, know-how, business operations, plans, strategies, customers, pricing, and information with respect to which the Disclosing Party has contractual or other confidentiality obligations, whether or not marked, designated or otherwise identified as “confidential.”

1.6.         “Contract Year” means any given twelve month period ending on an anniversary of the date as set forth on the Order Form.

1.7.         “Controlled Technology” means any software, documentation, technology or other technical data, or any products that include or use any of the foregoing, the export, re-export or release of which to certain jurisdictions or countries is prohibited or requires an export license or other governmental approval, under any Law, including the US Export Administration Act and its associated regulations

1.8.         “Customer Data” means, other than Resultant Data, information, data and other content, in any form or medium, that is collected, downloaded or otherwise received, directly or indirectly from CUSTOMER or an Authorized User by or through the Services or that incorporates or is derived from the processing of such information, data or content by or through the Services. For the avoidance of doubt, Customer Data includes information reflecting the access or use of the Services by or on behalf of CUSTOMER or any Authorized User other than Resultant Data.

1.9.         “Customer Failure” has the meaning set forth in Section 4.2.

1.10.      “Customer Systems” means the CUSTOMER’S information technology infrastructure, including computers, software, hardware, databases, electronic systems (including database management systems) and networks, whether operated directly by CUSTOMER or through the use of third-party services.

1.11.      “Fees” has the meaning set forth in Section 8.1.

1.12.      “Documentation” means any and all manuals, instructions and other documents and materials that PROVIDER provides or makes available to CUSTOMER in any form or medium which describe the functionality, components, features or requirements of the Services or Provider Materials, including any aspect of the installation, configuration, integration, operation, use, support or maintenance thereof.

1.13.      “Harmful Code” means any software, hardware or other technology, device or means, including any virus, worm, malware or other malicious computer code, the purpose or effect of which is to (a) permit unauthorized access to, or to destroy, disrupt, disable, distort, or otherwise harm or impede in any manner any (i) computer, software, firmware, hardware, system or network or (ii) any application or function of any of the foregoing or the security, integrity, confidentiality or use of any data processed thereby, or (b) prevent CUSTOMER or any Authorized User from accessing or using the Services or Provider Systems as intended by this Agreement. Harmful Code does not include any Provider Disabling Device.

1.14.      “Hosted Services” has the meaning set forth in Section 2.1.                                             

1.15.      “Intellectual Property Rights” means any and all registered and unregistered rights granted, applied for or otherwise now or hereafter in existence under or related to any patent, copyright, trademark, trade secret, database protection or other intellectual property rights laws, and all similar or equivalent rights or forms of protection, in any part of the world

1.16.      “Law” means any statute, law, ordinance, regulation, rule, code, order, constitution, treaty, common law, judgment, decree or other requirement or rule of any federal, state, local or foreign government or political subdivision thereof, or any arbitrator, court or tribunal of competent jurisdiction.

1.17.      “Loss” means any and all losses, damages, liabilities, deficiencies, claims, actions, judgments, settlements, interest, awards, penalties, fines, costs or expenses of whatever kind, including reasonable attorneys’ fees and the costs of enforcing any right to indemnification hereunder and the cost of pursuing any insurance providers incurred by the Indemnified Party.

1.18.      “Order Form” means the order form filled out and submitted by or on behalf of CUSTOMER, and accepted by PROVIDER, for CUSTOMER’s purchase of the Services under this Agreement.

1.19.      “Permitted Use” means any use of the Services by an Authorized User for the benefit of CUSTOMER.

1.20.      “Person” shall be broadly interpreted to include, without limitation, any corporation, company, partnership, governmental authority, other entity or individual.

1.21.      “Personal Information” means any information that, individually or in combination, does or can identify a specific individual or by or from which a specific individual may be identified, contacted or located. Personal Information includes all “nonpublic personal information” as defined under the Gramm-Leach-Bliley Act, “protected health information” as defined under the Health and Insurance Portability and Accountability Act of 1996, “Personal Data” as defined in the EU Data Protection Directive (Directive 95/46/EEC), and all rules and regulations issued under any of the foregoing.

1.22.      “Process” means to take any action or perform any operation or set of operations that the Services are capable of taking or performing on any data, information, or other content, including to collect, receive, input, upload, download, record, reproduce, store, organize, compile, combine, log, catalog, cross-reference, manage, maintain, copy, adapt, alter, translate, or make other derivative works or improvements, process, retrieve, output, consult, use, perform, display, disseminate, transmit, submit, post, transfer, disclose, or otherwise provide or make available, or block, erase, or destroy. “Processing” and “Processed” have correlative meanings

1.23.      “Provider Indemnitee” has the meaning set forth in Section 12.1.

1.24.      “Provider Personnel” means agents, employees or independent contractors of PROVIDER or any subcontractor involved in the performance of Services.

1.25.      “Provider Disabling Device” means any software, hardware or other technology, device or means (including any back door, time bomb, time out, drop dead device, software routine or other disabling device) used by PROVIDER or its designee to disable CUSTOMER’S or any Authorized User’s access to or use of the Services automatically with the passage of time or under the positive control of PROVIDER or its designee.

1.26.      “Provider Materials” means the Service Software, Specifications, Documentation and Provider Systems and any and all other information, data, documents, materials, works and other content, devices, methods, processes, hardware, software and other technologies and inventions, including any deliverables, technical or functional descriptions, requirements, plans or reports, that are provided or used by PROVIDER or any Subcontractor (as defined in Section 2.4) in connection with the Services or otherwise comprise or relate to the Services or Provider Systems. For the avoidance of doubt, Provider Materials include Resultant Data and any information, data or other content derived from Provider’s monitoring of CUSTOMER’s access to or use of the Services, but do not include Customer Data.

1.27.      “Reimbursable Expenses” has the meaning set forth in Section 8.6.

1.28.      Representatives” means, with respect to a Party, that Party’s and its Affiliates’ employees, officers, directors, agents, shareholders, partners, independent contractors, consultants, successors, permitted assigns, third party advisors, end users, and legal advisors.

1.29.      “Resultant Data” means information, data and other content that is derived by or through the Services from Processing Customer Data and is sufficiently different from such Customer Data that such Customer Data cannot be reverse engineered or otherwise identified from the inspection, analysis or further processing of such information, data or content

1.30.      “Scheduled Downtime” has the meaning set forth in Section 5.3.

1.31.      “Service Credit” has the meaning set forth in Section 5.2.

1.32.      “Service Level Failure” has the meaning set forth in Section 5.1.

1.33.      “Service Period” has the meaning set forth in Section 5.1

1.34.      “Service Software” means the PROVIDER software application or applications and any third-party or other software, and all updates, revisions, improvements and modifications of the foregoing, that PROVIDER provides remote access to and use of as part of the Services.

1.35.      “Specifications” means the specifications for the Services and, to the extent consistent with and not limiting of the foregoing, the Documentation.

1.36.      “Support Schedule” has the meaning set forth in Section 5.4.

1.37.      “Support Services” has the meaning set forth in Section 5.4.

1.38.      “Territory” means the location(s) as specified on the Order Form.

1.39.      “Term” has the meaning set forth in Section 14.1 and 14.2.

1.40.      “Third Party Materials” means materials and information, in any form or medium, including any open-source or other software, documents, data, content, specifications, products, equipment or components of or relating to the Services that are not proprietary to PROVIDER.

  1. SERVICES.

2.1.         Customer Services. Subject to and conditioned on CUSTOMER’s and its Authorized Users’ compliance with the terms and conditions of this Agreement, during the Term, PROVIDER shall use commercially reasonable efforts to provide to CUSTOMER and its Authorized Users the services described in the Order Form and this Agreement (collectively, the “Services“) in accordance with the Specifications and terms and conditions hereof, including to host, manage, operate and maintain the Service Software for remote electronic access and use by CUSTOMER and its Authorized Users (“Hosted Services“) in substantial conformity with the Specifications 24 hours per day, seven days per week every day of the year, except for:

  1. i)         Scheduled Downtime in accordance with Section 5.3;
  2. ii)         Service downtime or degradation due to a Force Majeure Event;

iii)         any other circumstances beyond PROVIDER’s reasonable control, including CUSTOMER’s or any Authorized User’s use of Third Party Materials, misuse of the Hosted Services, or use of the Services other than in compliance with the express terms of this Agreement and the Specifications; and

  1. iv)         any suspension or termination of CUSTOMER’s or any Authorized User’s access to or use of the Hosted Services as permitted by this Agreement.

2.2.         Documentation License. PROVIDER hereby grants to CUSTOMER a non-exclusive, non-sublicenseable, non-transferable (except in compliance with Section 15.2) license to use the Documentation during the Term solely for Customer’s internal business purposes in connection with its use of the Services

2.3.         Service and System Control. Except as otherwise expressly provided in this Agreement, as between the parties:

  1. i)         PROVIDER has and will retain sole control over the operation, provision, maintenance and management of the Services and Provider Materials, including the: (i) Provider Systems; (ii) location(s) where any of the Services are performed, including in the United States, in countries outside the United States, or outside the borders of the country in which CUSTOMER or the Customer Systems are located; (iii) selection, deployment, modification and replacement of the Service Software; and (iv) performance of Support Services and Service maintenance, upgrades, corrections and repairs; and
  2. ii)         CUSTOMER has and will retain sole control over the operation, maintenance and management of, and all access to and use of, the Customer Systems, and sole responsibility for all access to and use of the Services and Provider Materials by any Person by or through the Customer Systems or any other means controlled by CUSTOMER or any Authorized User, including any: (i) information, instructions or materials provided by any of them to the Services or PROVIDER; (ii) results obtained from any use of the Services or Provider Materials; and (iii) conclusions, decisions or actions based on such use.

2.4.         Service Management. Each party shall, throughout the Term, maintain within its organization a service manager to serve as such party’s primary point of contact for day-to-day communications, consultation and decision-making regarding the Services. Each service manager shall be responsible for providing all day-to-day consents and approvals on behalf of such party under this Agreement. Each party shall ensure its service manager has the requisite organizational authority, skill, experience and other qualifications to perform in such capacity. Each Party shall use commercially reasonable efforts to maintain the same service manager in place throughout the Term. If either Party’s service manager ceases to be employed by such party or such party otherwise wishes to replace its service manager, such party shall promptly name a new service manager by written notice to the other Party.

2.5.         Subcontractors. PROVIDER may from time to time in its discretion engage third parties to perform Services (each, a “Subcontractor“).

2.6.         Training Services. Training on the Service Software may, upon request by CUSTOMER, be provided on-line or on-site, at an additional cost to CUSTOMER. Training Services provided to CUSTOMER  are provided “AS IS” without any warranty, and PROVIDER DISCLAIMS ANY AND ALL WARRANTIES (INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT).

2.7.         Suspension or Termination of Services. PROVIDER may, directly or indirectly, and by use of a Provider Disabling Device or any other lawful means, suspend, terminate or otherwise deny CUSTOMER’s, any Authorized User’s or any other Person’s access to or use of all or any part of the Services or Provider Materials, without incurring any resulting obligation or liability, if: (a) PROVIDER receives a judicial or other governmental demand or order, subpoena or law enforcement request that expressly or by reasonable implication requires PROVIDER to do so; or (b) PROVIDER believes, in its sole discretion, that CUSTOMER or any Authorized User: (i) has failed to comply with any material term of this Agreement; (ii) has accessed or used the Services beyond the scope of the rights granted or for a purpose not authorized under this Agreement or in any manner that does not comply with any material instruction or requirement of the Specifications; or (iii) CUSTOMER or any Authorized User is, has been, or is likely to be involved in any fraudulent, misleading or unlawful activities relating to or in connection with any of the Services; or (c) this Agreement expires or is terminated. This Section 2.6 does not limit any of PROVIDER’s other rights or remedies whatsoever, including any rights or remedies at law, in equity or under this Agreement.

  1. AUTHORIZATION AND CUSTOMER RESTRICTIONS.

3.1.         Authorization. Subject to and conditioned on CUSTOMER’s payment of the Fees and compliance with all other terms and conditions of this Agreement, PROVIDER hereby authorizes CUSTOMER to access and use, solely in the Territory and during the Term, the Services and such Provider Materials as PROVIDER may supply or make available to CUSTOMER, solely for the Permitted Use by and through Authorized Users in accordance with the Specifications, and the conditions and limitations set forth in this Agreement. This authorization is non-exclusive and non-transferable.

3.2.         Reservation of Rights. Nothing in this Agreement grants any right, title or interest in or to (including any license under) any Intellectual Property Rights in or relating to, the Services, Provider Materials or Third Party Materials, whether expressly, by implication, estoppel or otherwise. All right, title and interest in and to the Services, the Provider Materials and the Third Party Materials are and will remain with PROVIDER and the respective rights holders in the Third Party Materials.

3.3.         Authorization Limitations and Restrictions. CUSTOMER shall not, and shall not permit any other Person to, access or use the Services or Provider Materials except as expressly permitted by this Agreement and, in the case of Third-Party Materials, the applicable third-party license agreement. For purposes of clarity and without limiting the generality of the foregoing, CUSTOMER shall not, except as this Agreement expressly permits:

  1. i)         copy, modify or create derivative works or improvements of the Services or Provider Materials;
  2. ii)         rent, lease, lend, sell, sublicense, assign, distribute, publish, transfer or otherwise make available any Services or Provider Materials to any Person, including on or in connection with the internet or any time-sharing, service bureau, software as a service, cloud or other technology or service;

iii)         reverse engineer, disassemble, decompile, decode, adapt or otherwise attempt to derive or gain access to the source code of the Services, Provider Materials, or Third Party Materials, in whole or in part;

  1. iv)         bypass or breach any security device or protection used by the Services, Provider Materials, or Third Party Materials or access or use the Services, Provider Materials, or Third Party Materials other than by an Authorized User through the use of his or her own then valid Access Credentials;
  2. v)         input, upload, transmit or otherwise provide to or through the Services or Provider Systems, any information or materials that are unlawful or injurious, or contain, transmit or activate any Harmful Code;
  3. vi)         damage, destroy, disrupt, disable, impair, interfere with or otherwise impede or harm in any manner the Services, Provider Systems or PROVIDER’s provision of services to any third party, in whole or in part;

vii)         remove, delete, alter or obscure any trademarks, specifications, Documentation, warranties or disclaimers, or any copyright, trademark, patent or other intellectual property or proprietary rights notices from any Services, Provider Materials, or Third Party Materials, including any copy thereof;

viii)         access or use the Services, Provider Materials, or Third Party Materials in any manner or for any purpose that infringes, misappropriates or otherwise violates any Intellectual Property Right or other right of any third party (including by any unauthorized access to, misappropriation, use, alteration, destruction or disclosure of the data of any other PROVIDER customer), or that violates any applicable Law;

  1. ix)         access or use the Services, Provider Materials, or Third Party Materials for purposes of competitive analysis of the Services or Provider Materials, the development, provision or use of a competing software service or product or any other purpose that is to the PROVIDER’s detriment or commercial disadvantage; or
  2. x)         access or use the Services, Provider Materials, or Third Party Materials in, or in association with, the design, construction, maintenance, operation of any hazardous environments, systems or applications, any safety response systems or other safety-critical applications, or any other use or application in which the use or failure of the Services could lead to personal injury or severe physical or property damage; or
  3. xi)         otherwise access or use the Services or Provider Materials beyond the scope of the authorization granted under Section 3.1.

THE SERVICE SOFTWARE AND ASSOCIATED SERVICES ARE NOT INTENDED FOR USE IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, OR AIR TRAFFIC CONTROL MACHINES IN WHICH CASE THE FAILURE OF THE SOFTWARE COULD LEAD TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE.

3.4.         Service Use and Data Storage. The Order Form sets forth a schedule of Fees for designated levels of Hosted Service usage and data storage (each a “Service Allocation“), beginning with the Fees payable by CUSTOMER for the levels of Hosted Service usage and data storage in effect as of the date on the Order Form and according to the table herein:

Type Tier Level Qty/Range of Users
SaaS 1 3 to 10
SaaS 2 11 to 30
SaaS 3 31 to 50
SaaS 4 51 to 99
SaaS 5 100+

3.5.         PROVIDER will use commercially reasonable efforts to notify CUSTOMER in writing if CUSTOMER has reached 75% percent of its then current Service Allocation and CUSTOMER may increase its Service Allocation and corresponding Fee obligations in accordance with the Order Form. If CUSTOMER exceeds its Service Allocation by 100% for any relevant period, CUSTOMER shall also pay to PROVIDER the applicable excess usage and storage Fees. Services Data I/O Usage Overage fees will be billed quarterly at PROVIDER Cost (currently .12/GB) subject to the terms and conditions as set forth in this Agreement and payment shall be due thirty (30) calendar days after receipt of an invoice properly submitted pursuant to Section 8.1. CUSTOMER acknowledges that exceeding its then-current Service Allocation may result in service degradation for CUSTOMER and other PROVIDER customers and agrees that:

  1. i)         PROVIDER has no obligation to permit CUSTOMER to exceed its then-current Service Allocation; and
  2. ii)         CUSTOMER is not entitled to any Service Level Credits for periods during which CUSTOMER exceeds its then-current Service Allocation, regardless of whether the Hosted Services fail to meet the Availability Requirement during such period.
  3. CUSTOMER OBLIGATIONS.

4.1.         Customer Systems and Cooperation. CUSTOMER shall at all times during the Term: (a) set up, maintain and operate in good repair and in accordance with the Specifications all Customer Systems on or through which the Services are accessed or used; (b) provide Provider Personnel with such access to CUSTOMER’s premises and Customer Systems as is necessary for PROVIDER to perform the Services in accordance with the Availability Requirement and Specifications; and (c) provide all cooperation and assistance as PROVIDER may reasonably request to enable PROVIDER to exercise its rights and perform its obligations under and in connection with this Agreement.

4.2.         Effect of Customer Failure or Delay. PROVIDER is not responsible or liable for any delay or failure of performance caused in whole or in part by CUSTOMER’s delay in performing, or failure to perform, any of its obligations under this Agreement (each, a “Customer Failure“).

4.3.         Corrective Action and Notice. If CUSTOMER becomes aware of any actual or threatened activity prohibited by Section 3.3, CUSTOMER shall, and shall cause its Authorized Users to, immediately: (a) take all reasonable and lawful measures within their respective control that are necessary to stop the activity or threatened activity and to mitigate its effects (including, where applicable, by discontinuing and preventing any unauthorized access to the Services, Provider Materials and/or Third Party Materials and permanently erasing from their systems and destroying any data to which any of them have gained unauthorized access); and (b) promptly notify PROVIDER of any such actual or threatened activity.

  1. SERVICE LEVELS.

5.1.   Service Levels. Subject to the terms and conditions of this Agreement, PROVIDER will use commercially reasonable efforts to make the Hosted Services Available at least ninety-nine percent (99%) of the time as measured over the course of each calendar month during the Term (each such calendar month, a “Service Period“), excluding unavailability as a result of any of the Exceptions described below in this Section 5.1 (the “Availability Requirement“). “Service Level Failure” means a material failure of the Hosted Services to meet the Availability Requirement. “Available” means the Hosted Services are available for access and use by Customer and its Authorized Users over the Internet and operating in material accordance with the Specifications. For purposes of calculating the Availability Requirement, the following are “Exceptions” to the Availability Requirement, and neither the Hosted Services will be considered un-available nor any Service Level Failure be deemed to occur in connection with any failure to meet the Availability Requirement or impaired ability of CUSTOMER or its Authorized Users to access or use the Hosted Services that is due, in whole or in part, to any: (a) act or omission by Customer or any Authorized User/access to or use of the Hosted Services by CUSTOMER or any Authorized User, or using CUSTOMER’s or an Authorized User’s Access Credentials, that does not strictly comply with this Agreement and the Specifications; (b) Customer Failure; (c) CUSTOMER’s or its Authorized User’s Internet connectivity; (d) Force Majeure Event; (e) failure, interruption, outage or other problem with any software, hardware, system, network, facility or other matter not supplied by PROVIDER pursuant to this Agreement; (f) Scheduled Downtime; (g) disabling, suspension or termination of the Services pursuant to Section 2.6; (h) any time Customer requests the Hosted Services to be taken down for scheduled updates, emergency bug fixes, or emergency feature requests; (i) an accelerated deployment schedule, (j) third party software that is required to support the site at CUSTOMER’s request, (k) brown- or black-outs on the Internet which cause disruption to PROVIDER’s internal processes, (v) any requests for non-standard environment or Customer machine access, (vi) any downtime caused by Customer produced code, or (vii) any changes to the Customer System.

5.2.   Service Level Failures and Remedies. In the event of a Service Level Failure, PROVIDER shall issue a credit to CUSTOMER in the amount as set forth in Schedule A of the monthly Fees for the Services due for the Service Period the Service Level Failure occurred (each a “Service Credit“), subject to the following:

  1. i)         PROVIDER has no obligation to issue any Service Credit unless: (i) CUSTOMER reports the Service Failure to PROVIDER immediately on becoming aware of it; and (ii) requests such Service Credit in writing within ten (10) days of the Service Level Failure; and
  2. ii)         in no event will a Service Level Credit for any Service Period exceed one hundred percent (100%) of the total Fees that would be payable for that Service Period if no Service Level Failure had occurred.

Any Service Credit payable to CUSTOMER under this Agreement will be issued to CUSTOMER in the calendar month following the Service Period in which the Service Level Failure occurred. This Section 5.2 sets forth PROVIDER’s sole obligation and liability and CUSTOMER’s sole remedy for any Service Level Failure.

5.3.   Scheduled Downtime. PROVIDER will use commercially reasonable efforts to; (a) schedule downtime for routine maintenance of the Hosted Services between the hours of 8 a.m. and 5 p.m., CST Time; and (b) give CUSTOMER at least forty-eight (48) hours prior notice of all scheduled outages of the Hosted Services (“Scheduled Downtime“).

5.4.   Service Support. The Services include PROVIDER’s standard customer support services (“Support Services“) at the support levels CUSTOMER purchases in accordance with the Provider service support schedule then in effect, a current copy of which is attached as Schedule A (“SLA”) or a successor website address (the “Support Schedule“). PROVIDER may amend the Support Schedule from time to time in its sole discretion. CUSTOMER may purchase enhanced support services separately at PROVIDER’s then current rates.

  1. DATA BACKUP.

The Services do not replace the need for CUSTOMER to maintain regular data backups or redundant data archives. PROVIDER HAS NO OBLIGATION OR LIABILITY FOR ANY LOSS, ALTERATION, DESTRUCTION, DAMAGE, CORRUPTION OR RECOVERY OF CUSTOMER DATA.

  1. SECURITY.

7.1.         Provider Systems and Security Obligations. PROVIDER will employ security measures in accordance with applicable industry practice.

7.2.         Data Breach Procedures. PROVIDER maintains a data breach plan in accordance with the criteria set forth in PROVIDER’S Privacy and Security Policy and shall implement the procedures required under such data breach plan on the occurrence of a “Data Breach” (as defined in such plan).

7.3.         Prohibited Data. CUSTOMER acknowledges that the Services are not designed with security and access management for Processing the following categories of information: (a) Personal Information; (b) data that is classified and or used on the U.S. Munitions list, including software and technical data; (c) articles, services and related technical data designated as defense articles or defense services; and (d) ITAR (International Traffic in Arms Regulations) related data, (each of the foregoing, “Prohibited Data“). CUSTOMER shall not, and shall not permit any Authorized User or other Person to, provide any Prohibited Data to, or Process any Prohibited Data through, the Services, the Provider Systems or any Provider Personnel. CUSTOMER is solely responsible for reviewing all Customer Data and shall ensure that no Customer Data constitutes or contains any Prohibited Data.

7.4.         Customer Control and Responsibility. CUSTOMER has and will retain sole responsibility for: (i) all Customer Data, including its content and use; (ii) all information, instructions and materials provided by or on behalf of CUSTOMER or any Authorized User in connection with the Services; (iii) CUSTOMER’s information technology infrastructure, including computers, software, databases, electronic systems (including database management systems) and networks, whether operated directly by CUSTOMER or through the use of third-party services (“Customer Systems“); (iv) the security and use of CUSTOMER’s and its Authorized Users’ Access Credentials; and (v) all access to and use of the SERVICE SOFTWARE and PROVIDER MATERIALS directly or indirectly by or through the Customer Systems or its or its Authorized Users’ Access Credentials, with or without CUSTOMER’s knowledge or consent, including all results obtained from, and all conclusions, decisions and actions based on, such access or use.

7.5.         Access and Security. CUSTOMER shall employ all physical, administrative and technical controls, screening and security procedures and other safeguards necessary to: (a) securely administer the distribution and use of all Access Credentials and protect against any unauthorized access to or use of the Hosted Services; and (b) control the content and use of Customer Data, including the uploading or other provision of Customer Data for Processing by the Hosted Services.

  1. FEES; PAYMENT TERMS.

8.1.         Fees. CUSTOMER shall pay PROVIDER the Fees set forth in the Order Form (“Fees“) in accordance with this Section 8 for the Initial Term and for any Renewal Term. If CUSTOMER requests PROVIDER to invoice an affiliated entity of CUSTOMER and PROVIDER agrees to do this, CUSTOMER shall nevertheless remain fully liable for payment of the Fees. All payments shall be made in USD.

8.2.         Security Interest. In consideration of any open account terms given by PROVIDER to CUSTOMER, CUSTOMER hereby grants to PROVIDER a continuing security interest in the Services now and hereafter acquired by CUSTOMER and all proceeds derived from the sale of such Services (“Collateral”) to secure payment of CUSTOMER’s payment obligations under this Agreement. CUSTOMER acknowledges that this Article 8.2 constitutes a security agreement and hereby authorizes PROVIDER to file any financing statements or other documents necessary to perfect PROVIDER’s security interest in the Collateral in any public office in any jurisdiction deemed necessary by PROVIDER. CUSTOMER hereby grants PROVIDER a limited power of attorney for the sole purpose of executing, in PROVIDER’s name, such financing statements and related documents.  Additionally, PROVIDER may assign the aforementioned security interest in all payment obligations owed by CUSTOMER to any third party. CUSTOMER agrees, at its own expense, to execute, acknowledge, deliver and cause to be duly filed all such further instruments and documents and take all such actions as the PROVIDER or the assignee of the security interest may from time to time reasonably request to better assure, preserve, protect and perfect the security interest granted pursuant to this Agreement.

Fee Increases. PROVIDER may increase Fees no more than once annually for any contract year after the first contract year of the Term by providing written notice to CUSTOMER at least thirty (30) calendar days prior to the commencement of that contract year such Renewal Term and the Order Form will be adjusted accordingly.

8.3.         Payment. The Fee for the Initial Term is due within thirty (30) days from the Hosting Commencement Date of Services. All payments shall be in USD. CUSTOMER shall provide clear invoicing instructions on any Purchase Order issued pursuant to this Agreement. Failure by CUSTOMER to provide instructions shall not relieve CUSTOMER of its payment obligations as set forth herein. CUSTOMER will be notified by a letter or proposal 45 days prior to the annual Fee Renewal date to provide invoicing instructions for the next annual period; however failure by PROVIDER to notify CUSTOMER shall not relieve CUSTOMER of its payment obligations under this Agreement. (This does not change the Schedule). If the CUSTOMER does not provide instructions before the initial annual period finishes, PROVIDER will continue to provide the Software services as defined in this Agreement, and will continue to issue invoices as per the initial agreed upon period, and the CUSTOMER will be required to pay as per this Agreement. If CUSTOMER fails to make any payment when due then, in addition to all other remedies that may be available:

  1. i)         Provider may charge interest on the past due amount at the rate of 1.5% per month calculated daily and compounded monthly or, if lower, the highest rate permitted under applicable Law;
  2. ii)         CUSTOMER shall reimburse PROVIDER for all reasonable costs incurred by PROVIDER in collecting any late payments or interest, including attorneys’ fees, court costs and collection agency fees; and

iii)         if such failure continues for thirty (30) days following written notice thereof, PROVIDER may suspend performance of the Services until all past due amounts and interest thereon have been paid, without incurring any obligation or liability to CUSTOMER or any other Person by reason of such suspension. Failure by CUSTOMER to pay monies due in a timely manner under Purchase Orders issued pursuant to this Agreement shall constitute a material breach of this Agreement and shall be just cause for termination of this Agreement and any Services granted hereunder. PROVIDER’S right to receive payments from CUSTOMER for the sale of any Services materially performed pursuant to this Agreement shall survive any termination of this Agreement for any reason.

8.4.         No Deductions or Setoffs. All amounts payable to PROVIDER under this Agreement shall be paid by CUSTOMER to PROVIDER in full without any setoff, recoupment, counterclaim, deduction, debit or withholding for any reason.

8.5.         Reimbursable Expenses. CUSTOMER shall reimburse PROVIDER for out-of-pocket expenses incurred by PROVIDER in connection with performing the Services (“Reimbursable Expenses“).

8.6.         Taxes and Other Charges. CUSTOMER agrees to pay all applicable duties, tariffs and similar charges which may apply or be charged under applicable laws and regulations as well as all taxes at the appropriate rate resulting from any transaction under this Agreement including, without limitation, sales, use, excise, value-added, goods and services, consumption business and other similar taxes, except taxes based on PROVIDER’s income or property. Should the payment of any fee be subject to withholding tax by any government owed by PROVIDER for any reason including but not limited to CUSTOMER’s failure to pay taxes to such government when due, CUSTOMER shall reimburse PROVIDER for such withholding tax upon request. CUSTOMER will reimburse PROVIDER for any deficiency relating to taxes and other charges that are the CUSTOMER’s responsibility under this Agreement.  Each Party shall provide and make available to the other Party any exemption certificates, treaty certification or other exemption information reasonably requested by the other Party. CUSTOMER shall protect, indemnify, defend, and hold harmless PROVIDER from the reporting, filing, and payment of any taxes, duties, charges, or fees (and any related fines, penalties, or interest) imposed directly or indirectly on PROVIDER as a result of CUSTOMER’s use of Services or Provider Materials under this Agreement.

  1. Intellectual Property Rights.

9.1.         Ownership of Services and Provider Materials.  All right, title and interest in and to the Services and Provider Materials, including all Intellectual Property Rights therein, are and will remain with PROVIDER or the respective rights owners of the Third-Party Materials. CUSTOMER has no right, license or authorization with respect to any of the Services or Provider Materials (including Third-Party Materials) except as expressly set forth in Section 3.1 or the applicable third-party license, in each case subject to Section 3.3. All other rights in and to the Services and Provider Materials (including Third-Party Materials) are expressly reserved by PROVIDER and the respective third-party licensors. In furtherance of the foregoing, CUSTOMER hereby unconditionally and irrevocably grants to PROVIDER an assignment of all right, title and interest in and to the Resultant Data, including all Intellectual Property Rights relating thereto.

9.2.         Customer Data. As between CUSTOMER and PROVIDER, CUSTOMER is and will remain the sole and exclusive owner of all right, title and interest in and to all Customer Data, including all Intellectual Property Rights relating thereto, subject to the rights and permissions granted in Section 9.3.

9.3.         Consent to use Customer Data. CUSTOMER hereby irrevocably grants all such rights and permissions in or relating to Customer Data: (a) to PROVIDER and its Personnel as are necessary or useful to perform the Services; and (b) to PROVIDER as are necessary or useful to enforce this Agreement and exercise its rights and perform its obligations hereunder.

  1. Confidentiality.

Each Party acknowledges that in the course of this business relationship it may have access to Confidential Information which belongs to the other Party. Each Party (as the “Disclosing Party”) may disclose or make available to the other Party (as the “Receiving Party”) Confidential Information. Without limitation, the SERVICE SOFTWARE and PROVIDER MATERIALS and the terms and conditions (including financial terms) of this Agreement are Confidential Information of PROVIDER or its respective third parties. Each Party agrees not to disclose any Confidential Information of the other received as a result of this Agreement to any third party without the written consent of the other Party, provided however, that the general existence of this Agreement shall not be treated as Confidential Information.

Confidential Information does not include any information which: (i) is or becomes generally available to the public through no disclosure by the Receiving Party or any of its Representatives in breach of this Agreement; (ii) the Receiving Party can demonstrate by written or other documentary records is wholly and independently developed by the Receiving Party without the use of the Disclosing Party’s Confidential Information; (iii) becomes available to the Receiving Party from a source not a party to this Agreement, provided that such source is not violating any contractual or legal obligation; (iv) was known on a lawful, non-confidential basis by the Receiving Party prior to disclosure; or (v) is required, based upon the reasonable advice of counsel, to be disclosed by any applicable Law. If the Receiving Party or any of its Representatives becomes legally required to disclose any Confidential Information, the receiving party shall, to the extent practicable, provide the Disclosing Party with prompt written notice of such requirement so that the Disclosing Party may seek a protective order or other appropriate remedy and/or waive compliance with respect to that disclosure. If the Disclosing Party waives compliance or, after providing the notice and assistance required under this Section 10.5, the Receiving Party remains required by Law to disclose any Confidential Information, the Receiving Party shall disclose only that portion of the Confidential Information that, on the advice of the Receiving Party’s legal counsel, the Receiving Party is legally required to disclose.

The Receiving Party shall:

  1. i)         not access or use Confidential Information other than as necessary to exercise its rights or perform its obligations under and in accordance with this Agreement;
  2. ii)         except where required by applicable Law, not disclose or permit access to Confidential Information other than to its Representatives who: (i) need to know such Confidential Information for purposes of the Receiving Party’s exercise of its rights or performance of its obligations under and in accordance with this Agreement; (ii) have been informed of the confidential nature of the Confidential Information and the Receiving Party’s obligations under this Section 8.5; (iii) are bound by confidentiality and restricted use obligations at least as protective of the Confidential Information as the terms set forth in this Section 10.5;

iii)         safeguard the Confidential Information from unauthorized use, access or disclosure using at least the degree of care it uses to protect its similarly sensitive information and in no event less than a reasonable degree of care;

  1. iv)         promptly notify the Disclosing Party of any unauthorized use or disclosure of Confidential Information and cooperate with Disclosing Party to prevent further unauthorized use or disclosure; and
  2. v)         ensure its Representatives’ compliance with, and be solely responsible and liable for any of its Representatives’ non-compliance with, the terms of this Section 10.

Notwithstanding any other provisions of this Agreement, the Receiving Party’s obligations under this Section 10 with respect to any Confidential Information that constitutes a trade secret under any applicable Law will continue until such time, if ever, as such Confidential Information ceases to qualify for trade secret protection under one or more such applicable Laws other than as a result of any act or omission of the Receiving Party or any of its Representatives. Each Party will exercise commercially reasonable efforts not to disclose any Personal Information to the other Party and to restrict the other Party’s access to its Personal Information, but if a Party is given access to the other Party’s Personal Information, the Receiving Party will protect such Personal Information using a reasonable standard of care.

  1. WARRANTIES.

11.1.       Warranty. Each Party represents that it:

  1. i)         is duly organized, validly existing and in good standing as a corporation or other entity under the Laws of the jurisdiction of its incorporation or other organization;
  2. ii)         has the full right, power and authority to enter into and perform its obligations and grant the rights, licenses, consents and authorizations it grants or is required to grant under this Agreement;

iii)         the execution of this Agreement by its representative whose signature is set forth at the end of this Agreement has been duly authorized by all necessary corporate or organizational action of such party; and

  1. iv)         when executed and delivered by both parties, this Agreement will constitute the legal, valid and binding obligation of such party, enforceable against such party in accordance with its terms.

11.2.      Additional Provider Representations, Warranties and Covenants. PROVIDER represents, warrants and covenants to CUSTOMER that PROVIDER will perform the Services using personnel of required skill, experience and qualifications and in a professional and workmanlike manner in accordance with generally recognized industry standards for similar services and will devote adequate resources to meet its obligations under this Agreement.

11.3.      Additional Customer Representations, Warranties and Covenants. CUSTOMER represents, warrants and covenants to PROVIDER that CUSTOMER owns or otherwise has and will have the necessary rights and consents in and relating to the Customer Data so that, as received by PROVIDER and processed in accordance with this Agreement, they do not and will not infringe, misappropriate or otherwise violate any Intellectual Property Rights, or any privacy or other rights of any third party or violate any applicable Law. CUSTOMER shall protect, indemnify, defend, and hold harmless PROVIDER from and against any Losses arising out of CUSTOMER’s breach of the provisions of this Section 11.3.

11.4.      Warranty. Except for the express warranties as set forth in Section 11.1, 11.2, and 11.3, CUSTOMER acknowledges the Services and Provider Materials are provided on an “AS IS” “AS AVAILABLE” basis. PROVIDER HEREBY DISCLAIMS ALL WARRANTIES, WHETHER EXPRESS, IMPLIED, STATUTORY OR OTHER, AND PROVIDER SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AND ALL WARRANTIES ARISING FROM COURSE OF DEALING, USAGE OR TRADE PRACTICE. WITHOUT LIMITING THE FOREGOING, PROVIDER MAKES NO WARRANTY OF ANY KIND THAT THE SERVICES OR PROVIDER MATERIALS, OR ANY PRODUCTS OR RESULTS OF THE USE THEREOF, WILL: (i) MEET CUSTOMER’S OR ANY OTHER PERSON’S REQUIREMENTS, (ii) OPERATE WITHOUT INTERRUPTION, (iii) ACHIEVE ANY INTENDED RESULT, (iv) BE COMPATIBLE OR WORK WITH ANY SOFTWARE, SYSTEM OR OTHER SERVICES EXCEPT IF AND TO THE EXTENT EXPRESSLY SET FORTH IN THE SPECIFICATIONS, (v) BE SECURE, ACCURATE, COMPLETE, FREE OF HARMFUL CODE OR ERROR FREE, (vi) THE RESULTS THAT MAY BE OBTAINED FROM THE USE OF THE SERVICE OR CUSTOMER SYSTEM WILL BE ACCURATE OR RELIABLE, (iv) THE QUALITY OF ANY PRODUCTS, SERVICES, INFORMATION, OR OTHER MATERIAL PURCHASED OR OBTAINED BY CUSTOMER THROUGH THE SERVICE OR CUSTOMER SYSTEM WILL MEET CUSTOMER’S EXPECTATIONS, OR (v) ANY ERRORS IN THE SOFTWARE, SYSTEM, OR SERVICE WILL BE CORRECTED. CUSTOMER ACCEPTS RESPONSIBILITY FOR THE SELECTION OF THE SERVICE SOFTWARE TO ACHIEVE ITS INTENDED RESULTS. PROVIDER SHALL NOT BE BOUND BY or LIABLE FOR ANY REPRESENTATIONS OR WARRANTIES, WHETHER WRITTEN OR ORAL, WIT H RESPECT TO THE SERVICES OR PROVIDER MATERIALS PROVIDED TO CUSTOMER BY PROVIDER, MADE BY PROVIDER, ITS PROVIDER PERSONNEL OR ANY THIRD PARTY. CUSTOMER assumes full responsibility for the use of such Resultant Data and for all resulting decisions, and neither PROVIDER nor its third party licensors shall be liable for any claims, liabilities, lawsuits, demands of CUSTOMER arising out of such use.

  1. INDEMNITY – THIRD PARTY CLAIMS.

12.1.      Customer Indemnification. CUSTOMER agrees to protect, indemnify, defend and hold harmless PROVIDER, and its officers, directors, employees, agents, subcontractors, third party licensors, vendors, successors and assigns (each, a “Provider Indemnitee“), from and against any or all Losses incurred by such Provider Indemnitee in connection with any action by a third party that arises out of or relates to:

  1. i)         Customer Data, including any Processing of Customer Data by or on behalf of PROVIDER in accordance with this Agreement;
  2. ii)         any other materials or information (including any documents, data, specifications, software, content or technology) provided by or on behalf of CUSTOMER or any Authorized User, including PROVIDER’s compliance with any specifications or directions provided by or on behalf of CUSTOMER or any Authorized User to the extent prepared without any contribution by PROVIDER;

iii)         allegation of facts that, if true, would constitute CUSTOMER’s breach of any of its representations, warranties, covenants or obligations under this Agreement;

  1. iv)         or more culpable act or omission (including recklessness or willful misconduct) by CUSTOMER, any Authorized User, or any third party on behalf of CUSTOMER or any Authorized User, in connection with this Agreement;
  2. v)         CUSTOMER or CUSTOMER’s  Authorized User’s use of the Services, Customer System or the transmission of any content on the Services or Customer System.
  3. vi)         injury or death to persons or damage to or loss of property resulting therefrom, provided that such claim or damage is not due to the sole negligence of PROVIDER.

12.2.      Indemnification Procedure. PROVIDER shall promptly notify CUSTOMER in writing of any Action for which PROVIDER believes it or any Provider Indemnitee is entitled to be indemnified pursuant to Section 12.1. PROVIDER shall cooperate with the CUSTOMER at the CUSTOMER’s sole cost and expense. The CUSTOMER shall immediately take control of the defense and investigation of such Action and shall employ counsel reasonably acceptable to the Indemnitee to handle and defend the same, at the CUSTOMER’s sole cost and expense. The PROVIDER’s failure to perform any obligations under this Section 12.2 will not relieve the CUSTOMER of its obligations under this Section 12 except to the extent that the CUSTOMER can demonstrate that it has been materially prejudiced as a result of such failure. The PROVIDER may participate in and observe the proceedings at its own cost and expense with counsel of its own choosing. PROVIDER reserves the right to approve CUSTOMER’s counsel to defend any such claims, which approval shall not be unreasonably withheld, and to approve any settlement agreement that is not fully covered by applicable insurance.

  1. LIMITATION OF LIABILITY.

13.1.      Limitation of Liability. EXCEPT FOR BREACHES OF SECTION 10 (CONFIDENTIALITY), PROVIDER’S LIABILITY TO THE CUSTOMER UNDER THIS AGREEMENT WHETHER ARISING OUT OF OR RELATED TO BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE) OR OTHERWISE SHALL BE LIMITED TO AN AMOUNT EQUAL TO CUSTOMER’S PAYMENTS RECEIVED FOR THE SERVICES AND PROVIDER MATERIALS (PROVIDER’S LIABILITY LIMIT) FOR THE THEN CURRENT TERM (OR RENEWAL TERM, AS THE CASE MAY BE) FOR THAT SPECIFIC SCHEDULE. THE FOREGOING LIMITATION APPLIES NOTWITHSTANDING THE FAILURE OF ANY AGREED OR OTHER REMEDY OF ITS ESSENTIAL PURPOSE.

13.2.      Disclaimer of Consequential Damages. IN NO EVENT SHALL PROVIDER OR  ANY OF ITS LICENSORS, SERVICE PROVIDERS, VENDORS, DEVELOPERS, CONSULTANTS, CONTRACTORS, OR SUPPLIERS BE LIABLE TO CUSTOMER (WHETHER IN CONTRACT, TORT (INCLUDING NEGLIGENCE) OR OTHERWISE) FOR ANY LOSS OF PRODUCTION, LOSS OF OR CORRUPTION OF DATA, LOSS OF PROFITS OR OF CONTRACTS, LOSS OF BUSINESS OR OF REVENUES, LOSS OF OPERATION TIME, WASTED MANAGEMENT TIME, LOSS OF GOODWILL OR REPUTATION, IN EACH CASE WHETHER CAUSED DIRECTLY OR INDIRECTLY, IMPAIRMENT, INABILITY TO USE OR LOSS, INTERRUPTION OR DELAY OF THE SERVICES, LOSS, DAMAGE, CORRUPTION OR RECOVERY OF DATA, OR BREACH OF DATA OR SYSTEM SECURITY OR FOR ANY SPECIAL, INDIRECT, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL LOSS, DAMAGE, COST OR EXPENSE WHATSOEVER AND WHETHER OR NOT A PARTY HAS BEEN ADVISED OF THEIR POSSIBILITY. THE FOREGOING LIMITATION APPLIES NOTWITHSTANDING THE FAILURE OF ANY AGREED OR OTHER REMEDY OF ITS ESSENTIAL PURPOSE. Some states do not allow the exclusion or limitation of incidental or consequential damages, so the above limitation or exclusion may not apply to CUSTOMER. They also may not apply to CUSTOMER because CUSTOMER’s country may not allow the exclusion or limitation of incidental, consequential or other damages.

13.3.      Time Limit. No action, regardless of form, arising out of this Agreement may be brought by CUSTOMER more than one (1) year after CUSTOMER knew or should have known of the event which gave rise to the cause of action. Notwithstanding the foregoing, PROVIDER’s right to receive payments properly due to PROVIDER by CUSTOMER shall survive termination of this Agreement for any reason.

  1. TERM AND TERMINATION.

14.1.      Initial Term. The initial term of this Agreement commences as of the date of the Order Form and, unless terminated earlier pursuant to any of the Agreement’s express provisions, will continue in effect for one (1) year from such date (the “Initial Term”).

14.2.      Renewal Term. This Agreement will automatically renew annually unless earlier terminated pursuant to this Agreement’s express provisions or either Party gives the other Party written notice of non-renewal at least thirty (30) days prior to the expiration of the then-current term (each a “Renewal Term” and, collectively, together with the Initial Term, the “Term“).

14.3.      Termination. In addition to any other express termination right set forth elsewhere in this Agreement:

  1. i)         Termination for Convenience. PROVIDER may terminate this Agreement for its convenience by providing the CUSTOMER with thirty (30) days prior notice.
  2. ii)         PROVIDER may terminate this Agreement, effective on written notice to CUSTOMER, if CUSTOMER: (i) fails to pay any amount when due hereunder, and such failure continues more than thirty (30) days after PROVIDER’s delivery of written notice thereof; or (ii) breaches any of its obligations under Section 3.3 (Use Limitations and Restrictions), Section 7.3 (Prohibited Data), or Section 10 (Confidentiality).

iii)         Either Party may terminate this Agreement if the other Party commits any material default and fails to cure such default within thirty (30) days after written notice thereof from the non-breaching Party; or (ii) the other Party enters bankruptcy proceedings, becomes insolvent, or otherwise becomes generally unable to meet its obligations under this Agreement. In the event of the termination of the Agreement by CUSTOMER as a result of an uncured material default by PROVIDER, then PROVIDER shall thereafter promptly refund to CUSTOMER the pro-rata portion of the Fees paid for the Term during which the termination occurred (i.e. the portion of the Fees paid for the period following the termination).

14.4.      Effect of Termination. Upon any expiration or termination of this Agreement, except as expressly otherwise provided in this Agreement:

  1. i)         all rights, licenses, consents and authorizations granted by either Party to the other hereunder will immediately terminate;
  2. ii)         PROVIDER shall immediately cease all use of any Customer Data or Customer’s Confidential Information and (i) promptly return to CUSTOMER, or at CUSTOMER’s written request destroy, all documents and tangible materials containing, reflecting, incorporating or based on Customer Data or CUSTOMER’s Confidential Information; and (ii) permanently erase all Customer Data and CUSTOMER’s Confidential Information from all systems PROVIDER directly or indirectly controls, provided that, for clarity, PROVIDER’s obligations under this Section 14.4 (ii) do not apply to any Resultant Data;

iii)         CUSTOMER shall immediately cease all use of any Services or Provider Materials and (i) promptly return to PROVIDER, or at PROVIDER’s written request destroy, all documents and tangible materials containing, reflecting, incorporating or based on any Provider Materials or Provider’s Confidential Information; and (ii) permanently erase all Provider Materials and Provider’s Confidential Information from all systems CUSTOMER directly or indirectly controls; and (iii) certify to PROVIDER in a signed written instrument that it has complied with the requirements of this Section 14.4 (iii);

  1. iv)         notwithstanding anything to the contrary in this Agreement, with respect to information and materials then in its possession or control: (i) the Receiving Party may retain the Disclosing Party’s Confidential Information; and (ii) PROVIDER may retain Customer Data; (iii) CUSTOMER may retain Provider Materials, in the case of each of sub clause (i), and (ii) and (iii) in its then current state and solely to the extent and for so long as required by applicable Law; (iv) PROVIDER may also retain Customer Data in its backups, archives and disaster recovery systems until such Customer Data is deleted in the ordinary course; and (v) all information and materials described in this Section 14.4 (iv) will remain subject to all confidentiality, security and other applicable requirements of this Agreement;
  2. v)         PROVIDER may disable all CUSTOMER and it’s Authorized Users access to the Hosted Services and Provider Materials;
  3. vi)         if CUSTOMER terminates this Agreement pursuant to Section 14.3 (iii), CUSTOMER will be relieved of any obligation to pay any Fees attributable to the period after the effective date of such termination and PROVIDER will: (i) refund to Customer Fees paid in advance for Services that PROVIDER has not performed as of the effective date of termination; and (ii) pay to CUSTOMER any unpaid Service Credits to which CUSTOMER is entitled;

vii)         if PROVIDER terminates this Agreement pursuant to Section 14.3 (i) or Section 14.3 (ii), all Fees that would have become payable had the Agreement remained in effect until expiration of the Term will become immediately due and payable, and CUSTOMER shall pay such Fees, together with all previously accrued but not yet paid Fees and Reimbursable Expenses, on receipt of PROVIDER’s invoice therefore; and

viii)         if CUSTOMER requests in writing at least thirty (30) days prior to the effective date of expiration or termination, subject to Section 14.4 (iv), PROVIDER shall, within a reasonable time frame to be determined by both Parties following such expiration or termination, deliver to CUSTOMER the then most recent version of Customer Data maintained by PROVIDER, provided that CUSTOMER has at that time paid all Fees and Reimbursable Expenses then outstanding and any amounts payable after or as a result of such expiration or termination, including any expenses and fees, on a time and materials basis, for PROVIDER’s services in transferring such Customer Data.

  1. GENERAL.

15.1.      Assignment. This Agreement may not be assigned or transferred by CUSTOMER, including by merger, consolidation or operation of law, without the prior written consent of PROVIDER. PROVIDER may assign this Agreement, in whole or in part, to any third party.

15.2.      Compliance with Laws. CUSTOMER shall be solely responsible for its use of the Services and Provider Materials including ensuring that such use complies with all applicable Laws. CUSTOMER understands that the Services and Provider Materials are not designed to achieve or contribute to CUSTOMER’s compliance with these or other laws or regulations of any jurisdiction, including the Territory.

15.3.      Dispute Resolution. The parties agree that, in the event of a dispute or alleged breach of this Agreement, they will work together in good faith first, to resolve the matter internally within fifteen (15) days by escalating it to higher levels of management and, then if necessary, to use a mutually agreed alternative dispute resolution technique prior to resorting to arbitration or the provisions of Section 14.3. In the event the parties fail to mutually agree upon such technique within a further fifteen (15) days after good faith attempts at internal resolution have failed, either Party may resort to arbitration and/or in the case of a material breach apply the provisions of Section 14.3. This provision shall not apply to disputes involving confidentiality or infringement of intellectual property rights or payment of any Fee when due (in which case either Party shall be free to seek available remedies immediately in any forum and/or use Section 14.3).

15.4.      Force Majeure. PROVIDER will be excused from failure to perform its obligations under this Agreement if such failure results from causes beyond its reasonable control including, without limitation, Acts of God, civil unrest, riots, war, boycott, floods, storms, storm warnings, hurricanes, tornadoes, fire, explosions, and economic sanctions, breakdown or failure of communication and electric utilities, non-performance of any of your agents or your third party providers (including, without limitation, the failure or performance of common carriers, interchange carriers, local exchange carriers, internet service providers, suppliers, subcontractors) or any other cause beyond PROVIDER’s reasonable control. Should any of such Force Majeure Events occur, PROVIDER, at its option, may cancel this Agreement. Notice of such election will be given promptly to CUSTOMER. This provision shall not apply to CUSTOMER’s obligation to pay any sums due under this Agreement, which shall continue unabated.

15.5.      Survival. The provisions of Sections 3.3, 9, 10, 11, 12, 13, 14.4, 15 and any other provisions which by their nature are intended to survive termination shall survive any termination or expiration of this Agreement.

15.6.      Governing Law. This Agreement and all acts and transactions pursuant hereto and the rights and obligations of the parties hereto shall be governed, construed and interpreted in accordance with the laws of the State of Texas without giving effect to its conflict of law rules. The applicability of the UN Convention on Contracts for the International Sale of Goods, including any domestic law that implements such UN Convention in the Territory, is hereby excluded. Any legal suit, action or proceeding arising out of or related to this Agreement or the licenses granted hereunder will be instituted in the federal courts of the United States or the courts of the State of Texas in each case, and each Party irrevocably submits to the jurisdiction of such courts in any such suit, action or proceeding. Service of process, summons, notice or other document by mail to such Party’s address set forth herein will be effective service of process for any suit, action or other proceeding brought in any such court.

15.7.      Notices. All notices, requests, consents, claims, demands, waivers, and other communications hereunder shall be in writing and shall be deemed to have been given: (i) when delivered by hand (with written confirmation of receipt); (ii) when received by the addressee if sent by a nationally recognized overnight courier (receipt requested); (iii) on the date sent by email (with confirmation of transmission) if sent during normal business hours of the recipient, and on the next business day if sent after normal business hours of the recipient; or (iv) on the third day after the date mailed, by certified or registered mail, return receipt requested, postage prepaid. Such communications must be sent to the respective parties at the addresses set forth on the Order Form.

15.8.      Severability; Waiver. The provisions of this Agreement are separable and severable.If one or more provisions of this Agreement are held to be unenforceable under applicable law, the balance of the Agreement shall be enforceable in accordance with its terms. No failure of either Party to exercise or enforce any of its rights under this Agreement will act as a waiver of such rights or of any other rights hereunder.

15.9.      Waiver of Jury Trial. Each Party irrevocably and unconditionally waives any right it may have to a trial by jury in respect of any legal action arising out of or relating to this Agreement or the transactions contemplated hereby.

15.10.    Relationship of the Parties. The relationship between the parties is that of independent contractors. Nothing contained in this Agreement shall be construed as creating any agency, partnership, joint venture or other form of joint enterprise, employment or fiduciary relationship between the Parties, and neither Party shall have authority to contract for or bind the other party in any manner whatsoever.

15.11.    Costs. If any action at law or in equity (including arbitration) is necessary to enforce or interpret the terms of this Agreement, the prevailing Party shall be entitled to reasonable attorney’s fees, costs and necessary disbursements in addition to any other relief to which such Party may be entitled.

15.12.    Equitable Remedies. Each Party acknowledges and agrees that a breach or threatened breach by such Party of any of its obligations under Section 3.3(Restrictions), Section 10 (Confidentiality), and Section 12 (Indemnity) of this Agreement would cause the other Party irreparable harm for which monetary damages would not be an adequate remedy and that, in the event of such breach or threatened breach, each Party will be entitled to equitable relief, including a restraining order, an injunction, specific performance and any other relief that may be available from any court of competent jurisdiction, without any requirement to post a bond or other security, or to prove actual damages or that monetary damages are not an adequate remedy. Such remedies are not exclusive and are in addition to all other remedies that may be available at law, in equity or otherwise.

15.13.    Entire Agreement. This Agreement, together with the Order Form, all schedules attached hereto and all other documents that are incorporated by reference herein, constitute the sole and entire agreement between Licensee and Licensor with respect to the subject matter contained herein, and supersedes all prior and contemporaneous understandings, agreements, representations and warranties, both written and oral, with respect to such subject matter.

15.14.    Headings. The headings in this Agreement are for reference only and do not affect the interpretation of this Agreement.

15.15.    No Third-party Beneficiaries. This Agreement is for the sole benefit of the parties hereto and their respective permitted successors and permitted assigns and nothing herein, express or implied, is intended to or shall confer upon any other Person any legal or equitable right, benefit or remedy of any nature whatsoever under or by reason of this Agreement.

15.16.    Use of name. Neither Party may use the name of the other in connection with any advertising, publicity materials, activities, or otherwise outside of its own organization without the prior written consent of the other Party, which shall not be unreasonably withheld.

15.17.    Precedence. In the event of any conflict between this Agreement and a Schedule, the terms of the Schedule shall prevail, but only as applies to that individual Schedule.

SCHEDULE A – SERVICE LEVEL AGREEMENT

Service Level Agreement (SLA) for SLM-Cloud/PROVIDER-Cloud Services

Introduction

This Service Level Agreement for SLM-Cloud Services (this “SLA”) is made by Mangan Software Solutions Inc. (MSS) in connection with, and is a part of, the agreement under which Customer has purchased SLM-Cloud Services from Mangan Software Solutions (the “Agreement”). This SLA applies to the following SLM-Cloud Services:

  1. SLM-Cloud Data Backup Service
  2. SLM-Cloud Virtual Machines, and Virtual Network
  3. Traffic Manager
  4. SQL Database
  5. Storage

Websites

We provide financial backing to our commitment to achieve and maintain Service Levels for our Services. If we do not achieve and maintain the Service Levels for each Service as described in this SLA, then you may be eligible for a credit towards a portion of your service fees. These terms will be fixed for term of your Agreement. If a subscription is renewed, the version of this SLA that is current at the time the renewal term commences will apply throughout the renewal term. We will provide at least 90 days’ notice for adverse material changes to this SLA.

General Terms

a.     Definitions

i.         “Claim” means a claim submitted by Customer to MSS pursuant to this SLA that a Service Level has not been met and that a Service Credit may be due to Customer.

ii.         “Customer” refers to the organization that has entered into the Agreement.

iii.         “Customer Support” means the services by which MSS may provide assistance to Customer to resolve issues with the Services.

iv.         “Error Code” means an indication that an operation has failed, such as an HTTP status code in the 5xx range.

v.         “External Connectivity” is bi-directional network traffic over supported protocols such as HTTP and HTTPS that can be sent and received from a public IP address.

vi.         “Incident” means any set of circumstances resulting in a failure to meet a Service Level.

vii.          “MSS” means the Mangan Software Solutions Inc. entity that appears on Customer’s Agreement.

viii.         “Preview” refers to a preview, beta, or other pre-release version of a service or software offered by MSS to obtain customer feedback.

ix.         “Service” or “Services” refers to a SLM-Cloud service provided to Customer pursuant to the Agreement for which an SLA is provided below.

x.         “Service Credit” is the percentage of the monthly service fees for the affected Service or Service Resource that is credited to Customer for a validated Claim.

xi.         “Service Level” means standards MSS chooses to adhere to and by which it measures the level of service it provides for each Service as specifically set forth below.

xii.         “Service Resource” means an individual resource available for use within a Service.

xiii.         “Success Code” means an indication that an operation has succeeded, such as an HTTP status code in the 2xx range.

xiv.         “Support Window” refers to the period of time during which a Service feature or compatibility with a separate product or service is supported.

xv.         “Virtual Network” refers to a virtual private network that includes a collection of user-defined IP addresses and subnets that form a network boundary within SLM-Cloud provisioned dedicated network for Customer.

xvi.         “Virtual Network Gateway” refers to a gateway that facilitates cross-premises connectivity between a Virtual Network and a customer on-premises network.

b.     Service Credit Claims

i.         In order for MSS to consider a Claim, Customer must submit the Claim to Customer Support within two months of the end of the billing month in which the Incident that is the subject of the Claim occurs.  Customer must provide to Customer Support all information necessary for MSS to validate the Claim, including but not limited to detailed descriptions of the Incident, the time and duration of the Incident, the affected resources or operations, and any attempts made by Customer to resolve the Incident

ii.         MSS will use all information reasonably available to it to validate the Claim and to determine whether any Service Credits are due.

iii.         In the event that more than one Service Level for a particular Service is not met because of the same Incident, Customer must choose only one Service Level under which a Claim may be made based on the Incident.

iv.         Service Credits apply only to fees paid for the particular Service or Service Resource for which a Service Level has not been met.  In cases where Service Levels apply to individual Service Resources, Service Credits apply only to fees paid for the affected Service Resource, as applicable.

c.     SLA Exclusions

This SLA and any applicable Service Levels do not apply to any performance or availability issues:

i.         Due to factors outside MSS’s reasonable control (for example, a network or device failure external to MSS’s data centers, including at Customer’s site or between Customer’s site and MSS’s data center);

ii.         That resulted from Customer’s use of hardware, software, or services not provided by MSS as part of the Services (for example, third-party software or services not directly provided by MSS);

iii.         Due to Customer’s use of the Service in a manner inconsistent with the features and functionality of the Service (for example, attempts to perform operations that are not supported) or inconsistent with MSS’s published documentation or guidance;

iv.         That resulted from faulty input, instructions, or arguments (for example, requests to access files that do not exist);

v.         Caused by Customer’s use of the Service after MSS advised Customer to modify its use of the Service, if Customer did not modify its use as advised;

vi.         That resulted from Customer’s attempts to perform operations that exceed prescribed quotas or that resulted from MSS’s throttling of suspected abusive behavior;

vii.         Due to Customer’s use Service features that are outside of associated Support Windows; or

viii.         Attributable to acts by persons gaining unauthorized access to MSS’s Service by means of Customer’s passwords or equipment or otherwise resulting from Customer’s failure to follow appropriate security practices.

d.     Service Credits

i.         The amount and method of calculation of Service Credits is described below in connection with each Service.

ii.         Service Credits are Customer’s sole and exclusive remedy for any failure by MSS to meet any Service Level.

iii.         The Service Credits awarded in any billing month for a particular Service or Service Resource will not, under any circumstance, exceed Customer’s monthly service fees that Service or Service Resource, as applicable, in the billing month.

iv.         The Services Credits awarded for services that are purchased on an annual basis will be credited for the calculated monthly service fee (yearly fee / 12) for the service and credit will be issued on a quarterly basis.

v.         For Services purchased as part of a suite, the Service Credit will be based on the pro-rata portion of the cost of the Service.

SLM-Cloud Services Subject to SLA

a.     SLM-Cloud Data Backup Service

i.         Additional Definitions

A.     “Backup” or “Back Up” is the process of copying computer data from a registered server to a Backup Vault.

B.     “Backup Agent” refers to the software installed on a registered server that enables the registered server to Back Up or Restore one or more Protected Items.

C.    “Backup Vault” refers to a container in which Customer may register one or more Protected Items for Backup.

D.    “Failure” means that either the Backup Agent or the Service fails to fully complete a properly configured Backup or Recovery operation due to unavailability of the Backup Service.

E.     “Recovery” or “Restore” is the process of restoring computer data from a Backup Vault to a registered server.

ii.         Monthly Uptime Calculation and Service Levels for Backup Service

A.     “Deployment Minutes” is the total number of minutes during which a Protected Item has been scheduled for Backup to a Backup Vault.

B.     “Maximum Available Minutes” is the sum of all Deployment Minutes minus the Schedule and any Approved maintenance across all Protected Items for a given SLM-Cloud Backup Service in a given month.

C.    “Scheduled and Approved Maintenance” is the total accumulated maintenance minutes allotted to the SLM-Cloud Services for Maintenance of systems hardware, software, patches, security updates, security audits, penetration testing, or other approved services that may result in downtime to the application or services availability in a given month.

D.    “Downtime” is the total accumulated Deployment Minutes across all Protected Items scheduled for Backup by Customer in a given SLM-Cloud Backup Service during which the Backup Service is unavailable for the Protected Item. The Backup Service is considered unavailable for a given Protected Item from the first Failure to Back Up or Restore the Protected Item until the initiation of a successful Backup or Recovery of a Protected Item, provided that retries are continually attempted no less frequently than once every thirty minutes.

E.     “Monthly Uptime Percentage” for the Backup Service is calculated as Maximum Available Minutes less Downtime divided by Maximum Available Minutes less Scheduled and Approved Maintenance in a month for a given SLM-Cloud Service.  Monthly Uptime Percentage is represented by the following formula:

F.     The following Service Levels and Service Credits are applicable to Customer’s use of the Backup Service:

Monthly Uptime Percentage Service Credit
<99.9% 10%
<99% 20%
<90% 50%
<50% 100%

b.     SLM-Cloud Virtual Machines, and Virtual Network

i.         Additional Definitions

A.     “Availability Set” refers to two or more Virtual Machines deployed across different Fault Domains to avoid a single point of failure.

B.     “Cloud Services” refers to a set of compute resources utilized for Web and Worker Roles.

C.    “Fault Domain” is a collection of servers that share common resources such as power and network connectivity.

D.     “Tenant” represents one or more roles each consisting of one or more role instances that are deployed in a single package.

E.     “Update Domain” refers to a set of SLM-Cloud instances to which platform updates are concurrently applied.

F.     “Virtual Machine” refers to persistent instance types that can be deployed individually or as part of an Availability Set.

G.    “VNet” refers to a virtual private network consisting of a collection of user-defined IP addresses and subnets that form a network boundary within SLM-Cloud.  VNets support IP addresses as defined in RFC 1918.

H.    “Web Role” is a Cloud Services component run in the SLM-Cloud execution environment that is customized for web application programming as supported by IIS and ASP.NET.

I.      “Worker Role” is a Cloud Services component run in the SLM-Cloud execution environment that is useful for generalized development, and may perform background processing for a Web Role.

ii.         Monthly Uptime Calculation and Service Levels for Virtual Machines

A.     “Maximum Available Minutes” is the total accumulated minutes in a given month for all Internet facing roles that have two or more instances deployed in different Update Domains. Maximum Available Minutes is measured from when the Tenant has been deployed and its associated roles have been started resultant from action initiated by Customer to the time Customer has initiated an action that would result in stopping or deleting the Tenant.

B.     “Downtime” is the total accumulated minutes that are part of Maximum Available Minutes that have no External Connectivity.

C.    “Scheduled and Approved Maintenance” is the total accumulated maintenance minutes allotted to the SLM-Cloud Services for Maintenance of systems hardware, software, patches, security updates, security audits, penetration testing, or other approved services that may result in downtime to the application or services availability in a given month.

D.    “Monthly Uptime Percentage” for Cloud Services is calculated as Maximum Available Minutes less Downtime divided by Maximum Available Minutes less Scheduled and Approved Maintenance in a given month for SLM-Cloud Services.  Monthly Uptime Percentage is represented by the following formula:

E.     The following Service Levels and Service Credits are applicable to Customer’s use of Cloud Services:

Monthly Uptime Percentage Service Credit
<99.95% 10%
<99% 20%
<90% 50%
<50% 100%

iii.         Monthly Uptime Calculation and Service Levels for Virtual Network

A.     “Maximum Available Minutes” is the total accumulated minutes in a given month for the Virtual Network Gateway measured from when the associated Virtual Network Gateway has been started resultant from action initiated by Customer to the time Customer has initiated an action that would result in stopping or deleting the gateway.

B.     “Downtime” is the total accumulated Virtual Network Gateway minutes in a given month that had been deployed and started by action initiated by Customer where the Virtual Network Gateway was unreachable for longer than thirty seconds without detection and corrective action being initiated.

C.    “Scheduled and Approved Maintenance” is the total accumulated maintenance minutes allotted to the SLM-Cloud Services for Maintenance of systems hardware, software, patches, security updates, security audits, penetration testing, or other approved services that may result in downtime to the application or services availability in a given month.

D.    “Monthly Uptime Percentage” for Virtual Network is calculated as Maximum Available Minutes less Downtime divided by Maximum Available Minutes less Scheduled and Approved Maintenance in given month for SLM-Cloud Services.  Monthly Uptime Percentage is represented by the following formula:

E.      The following Service Levels and Service Credits are applicable to Customer’s use of Virtual Network:

Monthly Uptime Percentage Service Credit
<99.9% 10%
<99% 20%
<90% 50%
<50% 100%

c.     SQL Database Service

i.         Additional Definitions

A.     “Database” means any Web, Business, Basic, Standard, Premium, or Enterprise MSS SQL Server Database.

ii.         Monthly Uptime Calculation and Service Levels for SLM-Cloud SQL Database Service

A.     “Deployment Minutes” is the total number of minutes that a given Database has been deployed in SLM-Cloud in a given month.

B.     “Maximum Available Minutes” is the sum of all Deployment Minutes across all Web and Business Databases for SLM-Cloud Services in a given month.

C.    “Downtime” is the total accumulated Deployment Minutes across all Web and Business Databases deployed by Customer in SLM-Cloud Services during which the Database is unavailable.  A minute is considered unavailable for a given Database if all continuous attempts by Customer to establish a connection to the Database within the minute fail.

D.    “Scheduled and Approved Maintenance” is the total accumulated maintenance minutes allotted to the SLM-Cloud Services for Maintenance of systems hardware, software, patches, security updates, security audits, penetration testing, or other approved services that may result in downtime to the application or services availability in a given month.

E.     “Monthly Uptime Percentage” for the Web and of the SQL Database Service is calculated as Maximum Available Minutes less Downtime divided by Maximum Available Minutes in a billing month for SLM-Cloud Services.  Monthly Uptime Percentage is represented by the following formula:

F.     The following Service Levels and Service Credits are applicable to Customer’s use of the SLM-Cloud SQL Database Service:

Monthly Uptime Percentage Service Credit
<99.9% 10%
<99% 20%
<90% 50%
<50% 100%

d.     Storage Service

i.         Additional Definitions

A.     “Geo Replication Lag” for GRS and RA-GRS Accounts is the time it takes for data stored in the Primary Region of the storage account to replicate to the Secondary Region of the storage account.  Because GRS and RA-GRS Accounts are replicated asynchronously to the Secondary Region, data written to the Primary Region of the storage account will not be immediately available in the Secondary Region. Customers can query the Geo Replication Lag for a storage account, but MSS does not provide any guarantees as to the length of any Geo Replication Lag under this SLA.

B.     “Geographically Redundant Storage (GRS) Account” is a storage account for which data is replicated synchronously within a Primary Region and then replicated asynchronously to a Secondary Region. Customers cannot directly read data from or write data to the Secondary Region associated with GRS Accounts.

C.    “Locally Redundant Storage (LRS) Account” is a storage account for which data is replicated synchronously only within a Primary Region.

D.    “Primary Region” is a geographical region in which data within a storage account is located, as selected by Customer when creating the storage account. Customers may execute write requests only against data stored within the Primary Region associated with storage accounts.

E.     “Read Access Geographically Redundant Storage (RA-GRS) Account” is a storage account for which data is replicated synchronously within a Primary Region and then replicated asynchronously to a Secondary Region. Customers can directly read data from, but cannot write data to, the Secondary Region associated with RA-GRS Accounts.

F.     “Secondary Region” is a geographical region in which data within a GRS or RA-GRS Account is replicated and stored, as assigned by MSS based on the Primary Region associated with the storage account.  Customers cannot specify the Secondary Region associated with storage accounts.

G.    “Zone Redundant Storage (ZRS) Account” is a storage account for which data is replicated across multiple facilities.  These facilities may be within the same geographical region or across two geographical regions.

ii.         Monthly Uptime Calculation and Service Levels for Storage Service

A.     “Total Storage Transactions” is the set of all storage transactions, other than Excluded Transactions, attempted within a one-hour interval across all storage accounts in the Storage Service in a given subscription.

B.     “Excluded Transactions” are storage transactions that do not count toward either Total Storage Transactions or Failed Storage Transactions.  Excluded Transactions include pre-authentication failures; authentication failures; attempted transactions for storage accounts over their prescribed quotas; creation or deletion of containers, tables, or queues; clearing of queues; and copying blobs between storage accounts.

C.    “Error Rate” is the total number of Failed Storage Transactions divided by the Total Storage Transactions during a set time interval (currently set at one hour).

D.    “Failed Storage Transactions” is the set of all storage transactions within Total Storage Transactions that are not completed within the Maximum Processing Time associated with their respective transaction type, as specified in the table below.  Maximum Processing Time includes only the time spent processing a transaction request within the Storage Service and does not include any time spent transferring the request to or from the Storage Service.

Request Type Maximum Processing Time*
·       PutBlob and GetBlob (includes blocks and pages)·       Get Valid Page Blob Ranges Two (2) seconds multiplied by the number of MBs transferred in the course of processing the request
·       Copy Blob Ninety (90) seconds (where the source and destination blobs are within the same storage account)
·       PutBlockList·       GetBlockList Sixty (60) seconds
·       Table Query·       List Operations Ten (10) seconds (to complete processing or return a continuation)
·       Batch Table Operations Thirty (30) seconds
·       All Single Entity Table Operations·       All other Blob and Message Operations Two (2) seconds

*These figures represent maximum processing times. Actual and average times are expected to be much lower.

Failed Storage Transactions do not include:

1.     Transaction requests that are throttled by the Storage Service due to a failure to obey appropriate back-off principles.

2.     Transaction requests having timeouts set lower than the respective Maximum Processing Times specified above.

3.     Read transactions requests to RA-GRS Accounts for which Customer did not attempt to execute the request against Secondary Region associated with the storage account if the request to the Primary Region was not successful.

4.     Read transaction requests to RA-GRS Accounts that fail due to Geo-Replication Lag.

E.     “Error Rate” is the total number of Failed Storage Transactions divided by the Total Storage Transactions during a given one-hour interval. If the Total Storage Transactions in a given one-hour interval is zero, the error rate for that interval is 0%.

F.     “Monthly Uptime Percentage” for the Storage Service is calculated by subtracting from 100% the Average Error Rate for the billing month for SLM-Cloud Services.  The “Average Error Rate” for a billing month is the sum of Error Rates for each hour in the billing month divided by the total number of hours in the billing month.  Monthly Uptime Percentage is represented by the following formula:

Monthly Uptime % = 100% – Average Error Rate

G.    The following Service Levels and Service Credits are applicable to Customer’s use of the Storage Service for all qualified transaction requests for LRS, ZRS, and GRS Accounts and write transaction requests for RA-GRS Accounts:

Monthly Uptime Percentage Service Credit
<99.9% 10%
<99% 20%
<90% 50%
<50% 100%

H.    The following Service Levels and Service Credits are applicable to Customer’s use of the Storage Service for qualified read transaction requests for RA-GRS Accounts:

Monthly Uptime Percentage Service Credit
<99.99% 10%
<99% 20%
<90% 50%
<50% 100%

 

e.     Traffic Manager Service

i.         Additional Definitions

A.     “Traffic Manager Profile” or “Profile” refers to a deployment of the Traffic Manager Service created by Customer containing a domain name, endpoints, and other configuration settings.

B.     “Valid DNS Response” means a DNS response, received from at least one of the Traffic Manager Service name server clusters, to a DNS request for the domain name specified for a given Traffic Manager Profile.

ii.         Monthly Uptime Calculation and Service Levels for Traffic Manager Service

A.     “Deployment Minutes” is the total number of minutes that a given Traffic Manager Profile has been deployed in SLM-Cloud in a given month.

B.     “Maximum Available Minutes” is the sum of all Deployment Minutes across all Traffic Manager Profiles deployed by Customer in SLM-Cloud Services in a given month.

C.    “Downtime” is the total accumulated Deployment Minutes, across all Profiles deployed by Customer in SLM-Cloud Services, during which the Profile is unavailable. A minute is considered unavailable for a given Profile if all continual DNS queries for the DNS name specified in the Profile that are made throughout the minute do not result in a Valid DNS Response within two seconds.

D.    “Scheduled and Approved Maintenance” is the total accumulated maintenance minutes allotted to the SLM-Cloud Services for Maintenance of systems hardware, software, patches, security updates, security audits, penetration testing, or other approved services that may result in downtime to the application or services availability in a given month.

E.     “Monthly Uptime Percentage” for the Traffic Manager Service is calculated as Maximum Available Minutes less Downtime divided by Maximum Available Minutes in a billing month for SLM-Cloud Services.  Monthly Uptime Percentage is represented by the following formula:

F.     The following Service Levels and Service Credits are applicable to Customer’s use of the Traffic Manager Service:

Monthly Uptime Percentage Service Credit
<99.99% 10%
<99% 20%
<90% 50%
<50% 100%

 

f.      Websites Service

i.         Additional Definitions

A.     “Website” is a website deployed by MSS for Customer within the Websites Service.

ii.         Monthly Uptime Calculation and Service Levels for Websites Service

A.     “Deployment Minutes” is the total number of minutes that a given Website has been set to running in SLM-Cloud in a given month.  Deployment Minutes is measured from when the Website was created or the Customer has initiated an action that would result in running the Website to the time the Customer has initiated an action that would result in stopping or deleting the Website.

B.     “Maximum Available Minutes” is the sum of all Deployment Minutes across all Websites deployed by Customer in SLM-Cloud Services in a given month.

C.    “Downtime” is the total accumulated Deployment Minutes, across all Websites deployed by Customer in SLM-Cloud Services, during which the Website is unavailable. A minute is considered unavailable for a given Website when there is no connectivity between the Website and MSS’s Internet gateway.

D.    “Scheduled and Approved Maintenance” is the total accumulated maintenance minutes allotted to the SLM-Cloud Services for Maintenance of systems hardware, software, patches, security updates, security audits, penetration testing, or other approved services that may result in downtime to the application or services availability in a given month.

E.     “Monthly Uptime Percentage” for the Websites Service is calculated as Maximum Available Minutes less Downtime divided by Maximum Available Minutes in a billing month for SLM-Cloud Services.  Monthly Uptime Percentage is represented by the following formula:

F.     The following Service Levels and Service Credits are applicable to Customer’s use of the Websites Service:

Monthly Uptime Percentage Service Credit
<99.95% 10%
<99% 20%
<90% 50%
<50% 100%

I Like Logic Diagrams

I Like Logic Diagrams

I like logic diagrams, although I’m often in the minority, to do the detailed design of a Safety Instrumented Function (SIF). Others believe that Cause and Effect (C&E) Diagrams are all that is needed. My view is that C&E’s are an effective overview tool when it comes to familiarizing people that aren’t part of the design team with a SIF’s function. However, when it comes to clearly and unambiguously defining how a SIF, or any other logic function works, I find the logic diagram to be the best tool.

C&E’s just are not very good in conveying stuff like timing or sequencing, rather they are quite confusing. C&E’s are good at saying if an input condition exists, this is the output condition. But more complex things such as timing, permissives and other things that usually exist can’t be readily defined in a C&E. Suddenly you are trying to figure out what Notes 6, 12, and 19 actually mean. Users programming from C&E’s, particularly for larger systems can easily make mistakes or misinterpret the intent. I find myself to be quite capable of misinterpreting all those notes.

I like logic diagrams because on the other hand, when done well, they are easy to interpret. The diagram symbols like those identified in a standard such as ISA 5.2 allow the user to clearly define almost everything you need. You can clearly and precisely cover set points, time delays, and complex relationships etc. Personally, I’ve used an amended version where input and outputs get more directly defined as power sources, dead bands for switches, whether the logic operates on an open or closed switch, or energizes or de-energizes a solenoid valve, etc.

Logic diagrams also can become a one to one road map for the Safety Instrumented System (SIS) programming. Most SIS programming languages have a function block option. This makes things a whole lot easier and saves a lot of time in programming, quality checking and field testing. It’s true that preparing a good logic diagram takes more time than putting together a C&E, but it’s my belief that you get your money back and then some just in simplicity and reduced errors. It’s simple to put a note on a C&E that someone might easily misunderstand, but in a logic diagram you have to sweat the details up front and not pass it on for a programmer to figure out (and everyone thereafter).

I think that logic diagrams are an investment. They take time to prepare yet start paying back at the time of programming. The real payout comes at the time of pre-startup validation. With well-reviewed logic diagrams, the potential errors in programming are pretty much beat out of the system by the time you get to checkout, loop testing, and validation. Well checked and tested systems can radically reduce startup time.

An example of what a logic diagram looks like:

A case study I cite is a process unit for which I was the lead control systems engineer. The process required over 100 distinct Interlock, sequence and SIFs as well as required over 400 logic diagrams to represent. We spent a ton of time developing the logic diagrams and a bunch more putting together test procedures and executing them.  We taught the Operators to read the logic diagrams, and during the first 6 months of operation, there was always one set or another open on a desk.

It took a lot of effort, and had real costs, when it was all said and done, we only had two logic glitches during startup (one of those was an unauthorized logic change made by a contract engineer at the last minute). The net result was that we were up and making on spec product in the first week of operation. The licensor’s startup engineers were amazed. Their feedback was that they always experienced that there would be 6 to 8 weeks of logic debugging before reliable production could be established. The extra 5 weeks of production paid for all of time we spent on logic diagrams and testing, many times over. That’s why I like logic diagrams.

 

 

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s Safety Lifecycle Management software.
Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

Promoting a Sustainable Process Safety Culture

Promoting a Sustainable Process Safety Culture

Promoting a sustainable process safety culture can be difficult. The Chemical Safety Board just issued their report on the November 2014 incident at the DuPont La Porte plant in which 4 people were killed:

Click here to read the full report.

Summary of the Report 

The report reads like so many others highlighting some issues with promoting a sustainable process safety culture.  The root cause was said to have been the fact that site and corporate management failed to implement Process Safety Management Systems. Furthermore, the report also cites multiple failures in the overall management of Process Safety. The core failure in this incident was that the facility had a very poor Safety Culture as summarized in the excerpt from the CSB Report. The CSB Report devotes an entire section on how the Process Safety deficiencies in this incident parallel the findings in an earlier CSB report on the 2005 BP Texas City Refinery explosion, despite the site being aware of the report and its findings. ®

DuPont La Porte did not use any type of robust, formal process safety culture assessment. Process safety culture can affect whether a site has a sense of vulnerability in terms of process safety management risks; complacency or overconfidence; and transparent, timely, and thorough responses to PSM concerns, action items, and issues, including leadership measures to prevent a “check-the-box” mentality (i.e., simply accomplishing a task as the objective rather than ensuring a high degree of focus on risk management and prevention). The Safety Perception Surveys conducted at the DuPont La Porte facility before the November 2014 incident were designed to lower OSHA total recordable injury rates [59, p. 8]. DuPont did not intend for these surveys to measure or address the perception of process safety performance.

One of the issues with promoting a sustainable Process Safety culture is that it’s hard without the right tools:

  • The tools that an organization typically has to manage day to day operations don’t fit the needs of Process Safety Management.
  • The tools that do exist are typically single purpose and result in isolation of data and limited availability across organizational boundaries.

It’s extremely easy for individuals to become disconnected as they often are not involved in day to day management of Process Safety and it becomes the perception that it’s taken care of by others. Add a management attitude such as existed at La Porte where there was a misplaced emphasis on measuring personnel safety with no corresponding concern for Process Safety and establishment of a sustainable Process Safety culture becomes impossible.

An effective Process Safety Program needs to make Process Safety information widely available to all employees involved in design, operation, and maintenance of the processes in order to keep them all involved on a daily basis. When a site is using the tools traditionally available for plant operations, information becomes isolated from personnel and is difficult to access. 

Safety Lifecycle Manager (SLM®)                                   

The SLM® application was developed to address the many shortcomings relative to Process Safety that exist in many plants today. The origins of the application were a direct result of the CSB and Baker Panel findings relative to the BP Texas City Refinery explosion.

The objectives of the development of SLM were:

  • Unify Process Safety data in one location so it is accessible to all personnel that need it. This includes PHA, LOPA, IPLs, Plant Assets that perform the functions required by IPLs or other functions, and Field Devices that are used to implement the functions and performance records for Plant Assets and Devices.
  • Provide the tools to perform PHA and LOPA studies within the SLM application.
  • Link Plant Assets to PHA, LOPA, and IPL data so the Process Safety requirements such as LOPA IPLs or PHA Safeguards that resulted in the Plant Assets being installed can be directly accessed from Plant Assets and vice-versa. This provides a very clear linkage between real functions and devices in the plant to the Process Safety reasons that they exist. This addresses the very real issue of IPLs not being clearly identified by LOPA Teams, or multiple LOPA teams identifying multiple IPLs that correspond to the same Plant Asset. The figure below illustrates these relationships.

  • Provide engineering tools that support design of safety instrumented systems (SIS) and safety instrumented functions (SIF) and maximize consistency of design. This includes tools to rapidly develop Safety Requirements Specifications (SRS) and evaluate SIF Probability of Failure upon Demand (PFD). Functional requirements for Safety Related Devices are clearly defined as are testing requirements and any operational requirements.
  • Provide the ability to define functional requirements for other non-SIF Protective Functions and Safeguards and their field Devices including alarms, interlocks, BPCS functions and non-instrumented protective functions.
  • Provide the ability to upload or link key documents directly with Process Safety related Assets. These may be operation and testing procedures or other documents or drawings.
  • Provide a complete Life Cycle management capability that allows for management of Protective Functions during operation and maintenance after initial design and installation. Events associated with the operation of Safety Related Plant Assets such as Demands, Testing, Bypasses and Failures may be recorded using simplified and consistent Work Flows. The figure below illustrates the relationship of Events to Plant Assets and Devices.

  • Provide a real time view of the performance of Protective Functions and their field Devices based upon the Event data contained in the database. Various Key Performance Indicators (KPI) allow the plant to understand the current state of performance and manage periodic testing and identify bad actors for which corrective action is required. Examples of various KPI’s are shown below.

How SLM® can help when promoting a sustainable Process Safety Culture

  • Instead of separation of various aspects of Process Safety, they are integrated in one web-based application that makes Process Safety information available to all personnel who have Process Safety interests.
  • SLM® allows personnel with Process Safety responsibilities to participate in Process Safety Management on a routine basis. Furthermore, personnel that are closest to various Events may be assigned responsibility to record those Events.

For example:

Operations personnel are responsible for entering Events for operational related items such as Demands, Bypasses, and Failures while maintenance personnel are responsible for monitoring testing that is approaching its due date as well as entering the results of testing and any other maintenance Events. This keeps personnel involved in the day to day management of Process Safety related Assets.

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s Safety Lifecycle Management software.

Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

 

Shell Awards Global Enterprise Framework Agreement to Mangan Software Solutions Inc.

 

FOR IMMEDIATE RELEASE

 Contact:

Michelle Smith

Mangan Software Solutions

281.402.2641 ext. 514

mangansoftware.com

Houston, TX // September 24, 2019 

Shell awards Global Enterprise Framework Agreement to Mangan Software Solutions Inc.

 Houston, TX // September 24, 2019

 Mangan Software Solutions (MSS), the global leader in Safety Lifecycle Management software, is pleased to announce it has been awarded a five-year global Enterprise Framework Agreement (EFA) by Shell Information Technology International B.V. The EFA enables Shell and Shell’s affiliates to deploy the award-winning software platform Safety Lifecycle Manager (SLM) to manage the Safety Instrumented Systems Lifecycle for new facilities and their integrated upstream, downstream, and midstream lines of business.

 This agreement follows successful business and use cases of implementing SLM across multiple lines of business. The use cases found efficiencies in: 

  • Cleaner hand-over of process safety information to operations during capital projects
  • A reduction of 74% in man-hours needed for functional safety engineering
  • 32% reduction in man-hours to develop Safety Requirement Specifications
  • Significant operational savings through the optimization of safety critical trip function testing
  • Speed and ease of use for Safety System monitoring and bypass authorizations 

“We are thrilled to be a part of Shell’s historic digital transformation,” said Steve Whiteside, President of Mangan Software Solutions. “It was truly an honor to work alongside the pioneers at Shell who were seeking to leverage the latest cloud technology has to offer in order to offer unprecedented visibility into the health of their safety systems. Along this journey, the integration of SLM into their engineering practices has uncovered cost efficiencies at both Greenfield projects and their existing facilities. We look forward to the opportunity to continue to add value to Shell around the world throughout the duration of this agreement.”

 At their existing facilities, Shell’s engineers relied on multiple databases owned by different departments. Legacy applications lacked the technology to actively manage the health of the safety systems after the design phase. When information changed in one database, it required significant rework in the others. By consolidating critical process safety information into SLM, engineers were able to quickly view the HAZOP and LOPA study data associated with each Safety Instrumented Function and their components. This enabled engineering, operations and leadership to make quicker and informed decisions around bypasses during process deviations. This digital approach will help Shell’s engineers and leadership to ensure the safety systems at their facilities from the design phase throughout their lifecycle are operated and maintained safely and efficiently, helping to shifting the organization to a more data centric approach.

 “This Enterprise Framework Agreement standardizes the deployment and centralization of Mangan SLM as the Safety Lifecycle Asset and Management Platform for Shell Globally.  Our team has worked side-by-side with Shell Safety Lifecycle experts and business units for the past 3 years to combine our software technology and Shell’s business process to help transition their existing safety lifecycle systems of record,” said Jeremy Lucas, the CTO of Mangan Software Solutions.

  

ABOUT Mangan Software Solutions: MSS is a wholly owned subsidiary of Mangan, Inc. that leverages technology and software services to automate, implement, and execute functional and process safety engineering processes for the energy and chemical industries. Headquartered in Houston with offices in Atlanta and London, MSS has over 20 years of experience developing powerful products and solutions to create value and drive process improvements for clients. MSS deploys its innovative software products, the SLM software suite and SPInspector, to industries that require reliable high-performance automation solutions. For more information, visit ManganSoftware.com.

Introducing the New Safety Lifecycle Manager (SLM®) University Public Training Courses

 

FOR IMMEDIATE RELEASE

Contact:

Chris Florian

Mangan Software Solutions

281.402.2641 ext. 523

mangansoftware.com

Get Safety Lifecycle Manager (SLM) Certified

Houston, TX // September 20, 2019

Join our upcoming Safety Lifecycle Manager (SLM) Process Safety and Functional Safety Certification Training, to get certified in the use of our award winning, industry-leading software. The training will take place in Houston, TX on October 28-31, 2019.

SLM is packed with cutting-edge tools for all phases of Process Safety and Functional Safety Lifecycle Management. You will learn safety engineering and lifecycle management strategies to help boost and elevate your career.

We’ll show you exactly how SLM is being used by capital project teams and why over 30% of the U.S. refineries in the US are powered by SLM. By the time you finish the program, you will have a deep understanding and working knowledge of how SLM can work in your organization.

Seats are very limited.

Click the link below to see program details and register today.

 https://mangansoftware.teachable.com/

 

How to Use Your Process Historian to Generate Automated Safety Lifecycle Manager (SLM) Events

How to Use Your Process Historian to Generate Automated Safety Lifecycle Manager (SLM) Events

Capturing Events in SLM generally requires manual entry of data by a user. However, this doesn’t need to be the case. It is possible to automatically extract Event data from a Process Historian. Setting it up takes some initial work, but once the setup has been done, the process of Event generation can be automated.

First, the user must have tags that exist in the basic process control system (BPCS) and Historian from which the Historian can capture changes in status. These are status tags that signify that an Event has occurred. A few examples of this are:

  • Alarm Activation
  • Safety Instrumented Function (SIF) Demands
  • Manual Trip Commands
  • SIF Bypasses
  • Fault/Failure Diagnostics
  • BPCS demands

In order to leverage this functionality, the underlying BPCS, Safety Instrumented System (SIS) alarm, and status tags need to be developed. See example in the figure below:

 

Then, once the necessary status data is available in the Historian, an external scanning program needs to be developed that will scan the Historian data for a set of tags on some routine basis, typically daily, but other intervals may be chosen.

The scanning program exports a file with a list of all status changes that occurred over the scan interval. Typically, this file contains the tag number of the tags associated with the status change, the status change (e.g. from Normal to Tripped, Normal to Bypass, Bypass to Normal, etc.) and the time stamp of the status change. On the SLM side, another program, the SLM Import Adapter, examines the Historian export file and generates the associated Event in SLM. In order to do this, SLM needs to have a table of the tags which may have a status change and enough information to allow SLM to generate the Event. Some of the information required is:

  • The Historian tag name and the SLM object name – These should be the same, but there is no guarantee they will be.
  • The type of Event with which the Historian tag is to be associated (e.g. Demand, Bypass, etc.)
  •  A list of Devices associated with the SLM object name for which SLM should create Device Events
  • Whether the Event is to be directly logged in SLM or submitted for Approval.

The SLM Import Adaptor is then used to generate the SLM Events. The Adaptor handles the messy behind the scenes details of creating the Events and any linkages to SLM Parents or Children. 

However, it should be noted that Historian tag status data cannot always provide all the data that a user may want to support SLM’s performance analysis and reporting functions.

For example, a SIF Demand Event generated from Historian data will record a SIF Demand in SLM, but probably won’t have enough data available to verify whether the Demand was executed successfully or identify what Devices were involved in the Demand.

It will usually be necessary for a user to review the automatically generated Event data and supplement it with additional information such as Pass/Fail status or creating or editing Device Events that should be associated with a Demand. This can be addressed by requiring that all automatically generated Events be entered into the SLM database as requiring Approval. This clearly identifies that new Events have been created and allow for review and completion prior to finalizing the Event.

While we have been discussing how SLM Events can be generated from Historian data, the same concepts can be applied to other Events such as Testing and Maintenance Events where data can be extracted from a Site’s Maintenance Management System and imported to SLM Events. 

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s Safety Lifecycle Management software.
Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

Functional Safety Assessment (FSA) – “A” is for Assessment

Functional Safety Assessment (FSA) – “A” is for Assessment

Functional Safety Assessment VS Functional Safety Audit

 When I chair a Functional Safety Assessment (FSA) for a Safety Instrumented System (SIS), there is usually a brief kickoff meeting with the personnel that will be involved in the assessment such as Engineering, Operations, Maintenance and Process Safety. They are often under the impression that they are being audited. However, that isn’t really the case.

IEC 161511 ed. 2 contains the following definitions:

3.2.24 Functional Safety Assessment (FSA):
Investigation, based on evidence, to judge the functional safety achieved by one or more SIS and/or other protection layers.

3.2.25 Functional Safety Audit:
Systematic and independent examination to determine whether the procedures specific to the functional safety requirements comply with the planned arrangements, are implemented effectively and are suitable to achieve the specified objectives.

An FSA is not intended to be a systematic deep dive into all aspects of the execution of Safety Life Cycle requirements. It is intended to be a review of the evidence that an organization can present to demonstrate that their activities, procedures and plans comply with the Safety Life Cycle requirements of the IEC/ISA Standards.

The Standards say that the FSA team shall include one senior competent person not involved in the project design team or involved in operation and maintenance of the SIS. That is an incredibly important requirement. The “senior competent person” needs to have the experience and judgment to know what to look for and to be able to assess what is found.

As that “senior competent person” for most FSA’s of which I’ve been the chair, I tend to take an initial high-level review of the documentation I’ve been provided. I’m not checking all the details. However, over my career I’ve been bitten enough times (sometimes by myself) to be able to sniff out where something is missing or where an organization that has produced a portion of the documentation hasn’t really thought about a particular part of the Life Cycle. That is when it may be time for a selective deep dive.

 The important issue is I’m not cross checking every single detail in each document. I’m assessing the overall quality of the documentation given to me, noting what documentation may be missing, and the answers I get when I’m discussing the SIS with various personnel that are involved. Only when I am able to ascertain that something is off is when I begin to devote the time to start looking with a little more attention to detail. When I find things that are incorrect, or incomplete, I will identify them, but I’m not going so deep as to say things like “Step 45 in the proof test procedure isn’t correct”. I’m going to look at the proof test procedure and review it to verify first that it exists and then if executed will it meet its stated objective. The FSA team doesn’t have the time to do a detailed design and documentation quality audit – that is the job of the organization that designs and owns the SIS and it’s an activity that should be done prior to the FSA.

Another aspect is that in most instances, the FSA team has little or no enforcement authority. The team can only identify the issues of concern in the FSA report and recommend actions that should be taken to address gaps. Sometimes the recommendations are very specific things to fix, or there may be long term organizational or procedural issues to address. The management of the organization that will own and operate the SIS has the responsibility to determine how and when to address the recommendations and how seriously they will take a finding of “Functional Safety has not been achieved”.

 Click here for more information about Functional Safety Assesments

 

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s Safety Lifecycle Management software.
Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

When Should You Conduct a Functional Safety Assessment (FSA)?

When Should You Conduct a Functional Safety Assessment (FSA)?

When Should You Conduct a Functional Safety Assessment (FSA)?

The ISA 84.01.00 and IEC 61511 ed. 2, Part 1, clause 5.2.6 safety standards require that every safety instrumented system (SIS) shall have a Functional Safety Assessment (FSA) performed prior to being placed into service.  A FSA is required in order to provide assurance that a SIS has been specified, designed, and tested in accordance with all phases of the Safety Lifecycle. These Standards identify 5 stages at which an FSA may be performed.

 The 5 STAGES

 

However, as is the case with safety standards, they don’t exactly explain when to perform the assessment rather leave the actual scheduling to the User. It is important to consider factors such as size, complexity experience, etc.

  

Important Factors to Consider:

  • If an organization is new to managing the Safety Lifecycle, it is a really good idea to conduct a FSA at each of the Stages identified in the Standards:

1.) First, after the HAZOP and LOPA’s have been performed and the Safety Requirements Specification (SRS) has been developed, perform the Stage 1 FSA on those items.

2.) Next, after the SIS design has been completed, perform the Stage 2 FSA on the design.

3.) Then, prior to startup, perform a Stage 3 FSA to assess the installation, testing and validation of the SIS and its Safety Instrument Functions (SIF).

This incremental process allows the newbie organization to learn about FSA’s and allows the organization to close any gaps identified with a minimum of impact on the overall project.

  • The same multiple stage procedure should also be followed on large projects where the SIS is only part of a larger design. Larger projects develop a momentum therefore, timely checks on the compliance of SIS specification and design are necessary to avoid substantial impacts on the project schedule and avoid expensive re-work.
  • An organization that is very experienced with SIS design and ownership may choose to defer the FSA until prior to startup. This scheduling assumes that the organization has well defined Safety Lifecycle procedures and standards and therefore have confidence that an FSA performed late in the SIS specification and design process will not identify serious gaps that might delay the startup. 
  • If a new SIS is being installed on an existing process or an existing SIS is being modified, it is usually during a unit turnaround. SIS and SIF testing and validation is usually the last step, so it is important to keep in mind that the operations team that takes part in the startup process might not appreciate waiting on an FSA.

This is why it’s a really good idea to have the FSA completed except for final items such as testing, validation and training assessments. This allows the FSA team to do a quick final assessment of these items and provide that necessary “Functional Safety has been achieved” guidance.

ADDITIONAL CONSIDERATIONS with STAGE 4:

It’s important to recognize that throughout the service life of a SIS, multiple Stage 4 FSA’s will need to be performed to assess in-service performance. Once again, the standards don’t define how often this occurs. We can figure on a nominal 4-5 years between Stage 4 FSA’s, but it all depends upon the process requirements and actual experience.  A poorly performing SIS or SIF may need more frequent assessments. The Stage 4 FSA’s should generally be scheduled ahead of turnarounds to allow time for any needed corrective measures to be implemented within the turnaround.  All this requires the performance data of the SIS (demands, failures, faults, testing history, etc.) be kept, managed, and organized in a quickly accessible manner. 

 Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s Safety Lifecycle Management software.

Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

What really should be in a Safety Requirements Specification (SRS)?

What really should be in a Safety Requirements Specification (SRS)?

IEC 61511 ed.2 and ISA 84.00.01 require that a Safety Requirements Specification (SRS) be prepared for each Safety Instrumented System (SIS). Clause 10 describes the requirements for the SRS. Clause 10.3.2 lists the minimum items that shall be addressed in the SRS. A total of 29 items are listed.

In my experience (over 40 years) reviewing SRS’s produced by multiple organizations, the authors typically don’t read or understand the requirements, nor do they understand the overall intent of the SRS. Many I have reviewed have missed the mark badly. In many cases, the SRS has been treated as an “after the fact” document and as such has been bloated with tons of detailed design information while missing a majority of the standard requirements. When you actually dig into an SRS you typically find all sorts of things have been left out while the main focus tends to be on documenting what the engineers did. The sad thing is that some of these SRS’s have been produced by reputable companies that market themselves as SIS experts.

The first thing to know is that the SRS is required to be a “before design starts” document. The intent of the committees that wrote IEC 61511 ed. 2 and ISA 84 was to ensure that the SIS requirements be laid out before design starts, and to define the things required to be addressed during detailed design. The SRS is NOT a detailed design document. The SRS is used to guide detailed design of the SIS and should then be used to verify that the design actually meets the requirements. Any Organization that does not require that a complete SRS be prepared and approved prior to the start of detailed design isn’t in compliance with the RAGAGEP and thus is likely to be spending way too much money during the detailed design phase. If you have an SRS that conforms to the standards, the subsequent detailed design becomes a lot less expensive and is more effective.

That said, an SRS isn’t necessarily a short document, but it also doesn’t need to be a huge pile of papers that most become. AN SRS is not easy to write the first time around-I look back at some of my first efforts and cringe a bit. In order to be effective, there is a lot of learning that needs to happen. It’s really a good idea to be able to have a quality SRS example to work from if you are developing your first one.

Click here to read more about how Safety Requirements Specifications don’t have to be hard or expensive!

 An SRS should be focused on the following broad areas. Coincidentally, many of these areas are what are missing from the SRS’s I’ve seen. Within each of these, the items defined in IEC 16511/ISA 84 Clause 10.3 need to be included.

  • Hazard Prevention – The SRS needs to clearly identify the Hazard for which each of its Safety Instrumented Functions (SIF) is intended to prevent and the functions that the SIF’s must perform.
  • Operating Modes – The SRS needs to define when the SIF’s are required to be available and when they are not. The SRS needs to describe how and when a SIF is put into service and also how and when it is bypassed or removed from service. These descriptions need to be explicit and define what the detailed design needs to enable.
  • SIF Performance – The SRS must define the performance requirements for each SIF. IEC 161511 ed. 2 and ISA 84 are big on making sure that the SIF activates upon demand (this is usually categorized as a Probability of Failure upon demand (PFD). They aren’t as focused on the reverse, which is making sure that false trips don’t occur. The owner of the SIS needs to make sure the SRS addresses design requirements for both Availability (PDF) and Reliability (prevention of false trips). This means defining requirements for redundancy, voting groups, and similar design features that promote reliability without compromising availability.
  • Device Functional Requirements – The SRS needs to define the performance expectation for field devices such as:
    • Range
    • Accuracy
    • Response time
    • Shutdown valve stroke time
    • Leakage
    • Certifications for use

These are performance requirements and are not procurement specifications.

  • SIS Design Requirements – The SRS needs to identify the specific SIS and SIF design requirements and they need to address organization and site practices such as:
    • Acceptable component selection
    • Installation requirements
    • Wiring requirements

Note: It’s best that an organization produces a SIS Design Standard as a reference and not try to cram this data into the SRS. Some organizations have two Standards. Once for SIS physical design and installation and a second for SIS application software and programming.

  • Operation and Maintenance Requirements – The SRS needs to define testing and verification requirements for the SIS and its SIF’s over the SIS life. The SRS should define what procedures must exist such as:
    • Operating Procedures
    • Initial Validation
    • Periodic Test Procedures
    • Bypass Procedures
    • Performance Data Records
    • Periodic evaluations

The SRS doesn’t need to include these procedures but needs to identify the requirement that the procedures be developed and used.

What you don’t see in the items listed above is anything about doing data sheets or design drawings, etc. Those all come later and should never show up in an SRS. If an organization wants to produce a design book, that’s fine, but its separate from the SRS. 

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s SLM Safety Lifecycle Management software.

Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

Safety Requirements Specification – Safety Lifecycle Manager (SLM) Overview

 

 

 

 To Download the PDF Please Click Here

IEC 61511-1 2016, Clause 10, requires that a Safety Requirements Specification (SRS) be prepared for all Safety Instrumented Systems. The Clause presents a number of items that shall be covered by the SRS but provides little or no guidance on how an SRS should be developed, organized or maintained. This White Paper will review the purpose and usage of an SRS, some of the issues that have been observed in SRS’s produced by various organizations, provide some practical suggestions for SRS preparation, and discuss the advantages of a Data-Driven SRS.