MASAS, Multi-Agency Situational Awareness System MASAS RFI
Print Page   |   Contact Us   |   Sign In
CanOps MASAS RFI
Share |

 

This RFI is now closed. Thank you to the many vendors that responded! The support for this new approach to delivering national public safety solutions is appreciated!

 

Table of Contents

Introduction

Background

CanOps Business Models

Supply Arrangements

Product Solution Envisioned

Responses

RFI Amendments, General Communications

RFI Distribution

Resources

About CanOps

About the CSSP

Questions / Answers (Q&A)

 

 

 

Introduction

  

This Request for Information (RFI) seeks to identify interested suppliers to the Canadian Public Safety Operations Organization (CanOps) for a suite of situational information management and communications capabilities based on the national Multi-Agency Situational Awareness System (MASAS) initiative, and possible supply model and technical solution options.

 

As this is CanOps first such supply arrangement, a two-step RFI / Request for Proposal (RFP) process is planned for; but not guaranteed. Further, there are no guarantees that CanOps will proceed with an agreement(s) based on the outcomes of this RFI.

 

Responses are due by 11:59 PM October 28 2016.

 

Background

  

In 2011, the national MASAS was identified as a national interoperability priority in the Action Plan of the Communications Interoperability Strategy for Canada (CISC).

 

The national MASAS has and continues to be owned and maintained by Defence Research and Development Canada’s Centre for Security Science (DRDC CSS). Current funding comes from the Canadian Safety and Security Program (CSSP), that is led by DRDC CSS in partnership with Public Safety Canada.

 

The MASAS operational pilot connected more than 500 operating units from all levels of government, and across all public safety sub-sectors. Some used interoperable commercial and custom software applications, and others the common MASAS web application, to capture and share situational information. The MASAS exercising mode was used in multi-agency exercises throughout the country, and across the border with the U.S. The developers “sandbox” offered vendors the opportunity to test their interoperability before deploying live with their clients.

 

Pilot success led to DRDC CSS and Public Works and Government Services (PWGS) conducting an RFI for approaches that would see MASAS continue forward. National governance was a priority, and only one response addressed it. In their submission, the Council of Canadian Fire Marshals and Fire Commissioners (CCFMFC) noted that there was no natural national organization to own and govern MASAS and other such systems, and that they would support the establishment of one for MASAS and other such public safety initiatives.

 

In the fall of 2014, efforts by CCFMFC and the (former) Canadian Association for Public Alerting and Notification (CAPAN) resulted in the formation of the Canadian Public Safety Operations Organization (CanOps). CanOps is a national not-for-profit corporation, with a mandate to provide operational, governance and ownership support to the Canadian public safety community, with a focus on national initiatives and systems like MASAS. CanOps not-for-profit governance structure includes a “Governing Members” membership class that is limited to senior public safety officials, and they select Directors, hold final approval of Bylaw changes, and through a gated approval process control the scope of CanOps activities.  

 

In September 2015 DRDC CSS contracted CanOps to provide governance administration, business operations, communications and outreach, and user technical support for MASAS. CanOps was also tasked with identifying a self-sufficient business model for MASAS.

 

Now, with two years of corporate experience, and a year of MASAS experience, CanOps is interested in advancing service offerings based on MASAS. Conducting this RFI is necessary to support the many business decisions ahead.

  


CanOps Business Models

 

CanOps is currently working with two primary business models. The first is based on one-off service agreements to a single party, such as the current service agreement in place with the federal government for the national MASAS. The second business model is for CanOps branded services that are to be available to CanOps members, such as those in mind relating to this RFI.

 

A rather simple and cost effective business legal framework is being developed for CanOps branded services, and it is based on membership and terms of use agreements. On behalf of an organization or operating unit, an authority is to commit the operating unit to the terms of membership. Representatives of the operating unit will be subject to terms of use agreements for specific products and services. Operating units are to be able to participate as members directly, or as an operating unit of a member organization. E.g. A municipal fire department could be a member, or the municipality could be the member and fire department associated with them. The same is planned for regional offices, detachments, etc. of federal, provincial and territorial governments.

 

The CanOps membership fee structure being considered includes a nominal membership fee per organization/operating unit, and a nominal fee per each named representative. This approach is easy to understand, scales well with the diversity of prospective members, and aligns with efforts to validate system users with members. Where practical, product and services fees will align with the membership fee structure.

 

CanOps expects to bundle some service offerings with membership. As an example, CanOps has subscribed to a leading membership engagement platform, the features of which may be available to all members and their working groups. The platform features private to group, private to members, and open to the public web pages, forums, blogs, calendars and group communications. The platform can even support the collection of dues for working groups.

 

Additionally, CanOps plans to recognize education, training, and exercising by its members personnel, through the issuance of certificates that individuals might use to demonstrate compliance with their provincial emergency management requirements, and to earn and retain accreditation with other organizations they may be members of. E.g. Trained to use MASAS, ran an exercise using MASAS.

 

CanOps aims to leave no public safety operating unit behind! Whereas most vendors cannot afford to sell to and support the smallest of municipalities, CanOps must find a way to do so! Supply arrangements that feature very low cost per user appear to be the answer.

 

Supply Arrangements

 

CanOps aims to govern, manage and administer a suite of CanOps branded products, to educate and train its members on the benefits and use of them, and to provide them with tier one support. CanOps does not however wish to own or host technology, and therefore aims to leverage supply arrangements with capable technology providers.

 

For services based on MASAS, CanOps believes a supply arrangement with an established vendor(s) already marketing and supporting solutions to the Canadian public safety community (and ideally abroad), and that recognizes the marketing value of association with CanOps in their pricing, may be required to deliver the value proposition CanOps aims to offer the very small municipal emergency management and response operating units.

 

CanOps only aims to offer “good” user interfaces that address the basic needs of all sub-sectors; similar to what has been offered with MASAS. This leaves plenty of upsell room for CanOps recognized supplier (and other vendors), to market “better” and more purpose specific solutions that also leverage the content CanOps supports the distribution and discovery of. Further, it is important to CanOps service and business objectives that there is a “somewhat better” and somewhat pricier solution to promote, to help manage expectations of CanOps “good”, lower cost, essential service, offerings. A key challenge for MASAS has been the sizeable cost gap between MASAS good interfaces and the next better solutions.

 

Ideally, CanOps supplier(s) will have a strong market presence, and play a leading role in the promotion of CanOps branded products.

 

At this time, and without the benefit of the feedback from this RFI, a price per user is the preferred pricing arrangement.


 

Product Solution Envisioned

  

The product solution envisioned goes further than MASAS. Whereas MASAS delivered the core capabilities of a “multi-agency” value proposition, CanOps aims to add more immediate and direct value for each user if it is to attract the critical mass of users required to deliver the multi-agency outcomes desired.

 

As with MASAS, the CanOps solution aims to be the leading source of authoritative unclassified non-sensitive situation information. The solution in mind includes a long list of situation information collections, including current incidents, planned events, road obstructions, service outages, and operations, as well as persistent infrastructure, resource, and hazard locations. Information discovery, such as service areas, community profiles, and known web and map situational information sources are also to be supported. Non-authoritative content (e.g. social media) is of interest as well; however the focus will remain on authoritative situational information.

 

Authorized members are to have the opportunity to contribute to the collections, and also to a private map from which they could quickly share their private mapped content. While the primary goal remains shared situational awareness, many stakeholders will only share when needed, and many of them are without the means to map their persistent information for sharing quickly. Further, many have made clear that the audience for what they share often needs to include the public, and that some of what is shared needs to be formatted as open data. E.g. Road obstructions shared as Open511 data, which is currently being experimented with.

 

Whereas MASAS only made information available for polling, and viewing in the MASAS common tools, CanOps wants to make push notification a key feature, as too few MASAS stakeholders were able to monitor MASAS. Authorized users are to have the opportunity of subscribing to an area of interest, and having transient information changes in that area pushed to them by email, and ideally by mobile app.

 

Technical applications (currently referred to as watchers) are required to monitor, poll, receive, format, and manage open and shared data used to populate specific collections.

 

A comprehensive identity management solution is required that will support the use of a single identity across products and platforms. Read and write rights per map collection, and limits on who can communicate with the public, will be managed by CanOps and member authorities. Interoperability with CanOps member engagement platform and ecommerce suppliers is desired, with the goal of a single sign-on for all things CanOps.

 

User interfaces need to support English and French use.

 

The selected supplier(s) can expect the opportunity to leverage some or all of the current MASAS software; some of which is coming to the end of its useful life. A plan for continuous improvement, including staying current with evolving web technology, is essential! Where and how the solution is hosted will be scrutinized by the diversity of CanOps members, which includes all levels of government, and security and privacy managers.

 

Replacing the current member engagement platform could be considered; with the understanding that it must operate independently of the other capabilities, and continue to support communications through any system failure.

 

To support a better understanding of what is envisioned, one or more interactive webinar presentations will be supported by CanOps MASAS Product Manager. The first is scheduled for October 4 2016, 2 PM Eastern. To register, go to https://attendee.gotowebinar.com/register/3909901109170615300.

  


Responses

 

RFI responses should include no less than the following:

 

  • Legal company name, legal address, web address(es), phone, fax
  • Name, title and contact information for the primary point of contact for this RFI, and the person(s) who will negotiate and sign any agreements
  • Describe company, including ownership, number of divisions, years in operation, annual revenues, current financial position, number of employees, strategic partnerships, …
  • Describe company’s current products and services, marketing efforts, sales channels, distribution arrangements, employee/contract sales, export sales, …
  • Describe company’s in-house and outsourced development capabilities, operational support, servers, processes, …
  • Describe the company’s quality processes, efforts, regular audits, disclosure, …
  • Describe the technical solution proposed, including the software, servers, third party services, country of origin of software and services used, …
  • Identify the company’s willingness to operate the current solution through transition
  • Describe the commitment to software support, maintenance, feature improvements, documentation, etc.
  • Provide an anticipated timeline through development, testing and launch of the next generation solution, including approval gates
  • Disclose any intellectual property and licensing considerations of the solution
  • Describe any specific marketing efforts that directly relate to the solution
  • Describe a preferred financial arrangement
  • Provide references; preferably clients from the public safety sector.
  • Identify any specific requirements of your corporation in respect to this agreement not already noted
  • Please share any lessons learned from other such arrangements

 

With respect to intellectual property, proponents should not disclose any information to CanOps that they consider to be confidential in their proposals. CanOps will not be signing non-disclosure agreements at this time.  

 

Responses are to be submitted by email to RFI@CanOps.org as one complete submission, with the information requested presented in a single document. Respondents are encouraged to make it as easy as possible for CanOps reviewers to get through their submission quickly and efficiently. Receipt of legitimate responses will be acknowledged.

 

Responses are due no later than 11:59 PM October 28 2016.

  


RFI Amendments, General Communications

 

Any amendments to this RFI, or additional communications, will be published on the CanOps MASAS website at the following URL https://canops.site-ym.com/page/RFI; which is linked to the primary MASAS webpage (www.MASAS.ca) on the CanOps (www.CanOps.orgwebsite.

 

CanOps aims for transparency through the process, and will post relevant questions and answers for all interested parties on the RFI webpage.


 

RFI Distribution

 

Awareness of this RFI includes emails to the respondents of the 2014 DRDC CSS MASAS RFI, and all vendors that have applied for and received MASAS accounts in the MASAS developers sandbox. Broader awareness of this RFI is being supported by the Canadian Interoperability Technology Interest Group (www.CITIG.ca), and the Canadian Advanced Technology Alliance (CATA) through their First Responder Vendor Outreach Forum in LinkedIn. Thanks to both!

 

All MASAS participants will be encouraged to share with their preferred suppliers as well.

 


Resources

 

The following resources are available to support prospective suppliers with their responses:

 

  1. Numerous MASAS resources available in the MASAS Resources section of the CanOps website. Click MASAS Resources at www.MASAS.ca
  2. A collection of MASAS technical guidance and source code, including the current and past MASAS user interfaces, can be found at https://projects.masas-sics.ca and https://api.masas-sics.ca/explorer/hub-2_2 .
  3. Access to the MASAS Development (“Sandbox”) environment, which offers the opportunity to use the current common user interface, and to capture and post through the current MASAS application program interface (API). Gaining access starts with an application at https://apply.masas-sics.ca.
  4.  Product definition documentation, including a slide presentation of desired changes to the current application, another slide presentation of desired changes to the current user interface, and desired workflows.
  5. Live (to be recorded) webinars, featuring presentations, live demonstrations, and Q&A relating to this RFI; the first of which is scheduled for October 4 2016, 2:00 PM Eastern. To register, go to https://attendee.gotowebinar.com/register/3909901109170615300.

  


About CanOps

 

The Canadian Public Safety Operations Organization (CanOps) is a new national not-for-profit service organization. It was established in the Fall of 2014 to provide operational support for Canadian multi-agency public safety initiatives that require the governance of senior public safety officials.

 

CanOps is providing governance administration, business operations, communications and outreach, and user technical support for the national Multi-Agency Situational Awareness System (MASAS).

 

For more information about CanOps, visit www.CanOps.org, or email info@CanOps.org

 

 

About the CSSP

 

MASAS is supported by the Canadian Safety and Security Program (CSSP), a federal program led by Defence Research and Development Canada’s Centre for Security Science (DRDC CSS), in partnership with Public Safety Canada.

 

The CSSP is a federally-funded program to strengthen Canada’s ability to anticipate, prevent/mitigate, prepare for, respond to, and recover from natural disasters, serious accidents, crime and terrorism through the convergence of science and technology with policy, operations and intelligence.

 

For more information about DRDC CSS and the CSSP, visit www.science.gc.ca/cssp , or email css-info@drdc-rddc.gc.ca

  


Questions / Answers (Q&A)

 

Q. Are you seeking to replace or compliment the current system?

A. CanOps would like to replace the current solution, and to support the current API for a period of time.

 

Q. Is the supplier responsible for hosting?

A. Yes. CanOps does not wish to own or maintain information technology.

 

Q. How do you see IP being handled? 

A. Interoperability without licensing is an objective, as is the ability to carry forward should the supply relationship come to an end, or the supplier be unable to meet their deliverables.

 

Q. What is the anticipated timeline for the RFP? Implementation?

A. Preferably, the next generation solution and business model will be in place by March 31 2017.

 

Q. Will the RFP be limited to RFI respondents?

A. Should there be an RFP, CanOps would expect to make such requests to a short list of suppliers that respond to the RFI.

 

Q. What is CanOps preferred funding model?

A. For CanOps branded services, the goal is to break even through user fees, and solution sponsors.

 

Q. Will pricing be based on the size of the organization?

A. We are working towards a simple pricing model based on a nominal fee per operating unit (member) and also per named user.

 

Q. Who will set the prices in the multi-tier solution aimed for?

A. CanOps will only set the price of its offerings. As noted in the RFI, a slightly better, slightly more expensive offering(s) supports business, branding, and positioning objectives, and makes clear that if members want more features, and solutions more specific to their sector, that they should look to the vendor community for an interoperable solution that offers such.

 

Q. Who will manage system access?

A. CanOps will manage system access to CanOps governed policies.

 

Q. How many MASAS users are there today? What is the breakdown?

A. There are more than 600 operating units associated with about 500 organizations, from all levels of government and sectors. There are also accounts with critical infrastructure stakeholders.

 

Q. Is the ArcGIS REST Feature Service still in Beta?

A. Yes. The next generation solution will offer more layers, and will ideally be managed within CanOps identity management solution.

 

Q. What is the plan for publishing to MASAS from ArcGIS?

A. We’d like a more efficient solution(s). For the most part we pull content from ArcGIS REST services, reformat the data, and manage it in the MASAS database. When time does not allow for this approach, we can share the content as a layer. A key objective of MASAS is to present what is out of the ordinary now without having to discover and open numerous layers of the same type of data to discover it. Looking ahead, we’d like to offer a layer output per data type. E.g. One for incidents, one for planned events, one for road obstructions, etc.

 

Q. Please clarify “watcher”.

A. They are data aggregation applications used to monitor data sources, and to manage content posting, updates and expires in the database. 

 

 

 

MASAS RFI Webinar Deck

Item Name Posted By Date Posted
MASAS RFI Webinar Deck PDF (3.16 MB) Administration 10/4/2016
Membership Software Powered by YourMembership  ::  Legal