InJo4.0 Center IoT Platform

Open Tender

October 2021

Innovate Jordan Jordan Industry 4.0 Digitalization Innovation Centre (InJo4.0)

Introduction Industry 4.0 and Digitalization means a fundamental change in the economic system, bringing tremendous

changes in the business processes and business models of industrial companies. For this purpose and

opportunities, a Jordanian-European Consortium Launched a project to establish Centre of Excellence

“InJo4.0” the only center of its kind in Jordan. This COE aims at supporting industries in Jordan and the region

to become more competitive and productive in the global, digital economy.

The center will bring together enterprises, academia, research centers, financial institutions, the civil society,

and any other actors to show them the practical way to implement and adopt Industry 4.0 solution, with

workshops, trainings and proof of concepts and demonstration of the existing solution.

2 Global objective InJo4.0 is seeking a solution provider for the set-up of the IOT Platform. The IOT platform would enable InJo4.0 center: a. to host digital platform to offer digital services to multiple clients, where multitenant capabilities is a must, in

addition to connect the center assets and demos to present the digital solution value to the project stakeholders, clients, and beneficiaries.

b. to offer access to ICT companies to develop their own application and publish it in the Solution provider marketplace.

The Platform will link machines data from to the digital world easily, quickly, and economically. Harnessing data from virtually any number of connected intelligent devices, enterprise systems and federated sources allow for analysis of real-time operational data. This analysis then leads to optimized processes, resource and productivity gains, the development of new operating and business models as well as the reduction of costs. InJo4.0 wants to set-up an IOT platform that comes with certain maturity, where all required core features are already implemented without the need for customizing. The InJo4.0 IOT Platform shall support both public cloud solution (SaaS) and/or on-premises, the availability of both options will be preferable. The scope of work in this Request for Proposal includes the following items:

1. provide flexible and agile license model to meet the two objectives mentioned above, either to offer one license model fit with them all or different license models.

2. The scope will be based on blanket/open agreement with fixed pricing for the coming two years, where there are no minimum license quantities must be ordered.

3. The envisioned number of licenses will as follow:

a. License to offers customized digital services to 20 clients, you can consider the center assets belong to one of the clients, number of assets per client will be defined on demand but the upgrade add-ons must be clear.

b. 10 licenses to be offered to the ICT to develop their own application.

If possible, item a and b can be merged into one license.

4. provide training to 15 participants. The training should enable them to be IoT certified engineers. This is an optional item. It will not be used in the financial evaluation. InJo4.0 have the right either to added to the project scope or remove it.

Important note to the bidders:

1. Based on the received Bids and the available budget, InJo4.0 project may award the tender to the two best offers.

2. Item 3.a and 3.b can be awarded to two different bidders in case we didn’t receive one solution meet both objectives.

3. The bidder needs to provide a proof of nationality under their national legislation – invoice should be issued from offices legally registered in EU MEMBER STATES countries or Jordan .

3 Scope of work 3.1 Business requirements 1. The IoT Platform must support key pillars of configurability, scalability and reusability.

The platform’s framework must support web-based backend services like Configuration & Aggregation services, Rules Engine, Diagnostic services, User Management services, configurable and efficient framework to visualize and contextualize data to help various stakeholders receiving meaningful and actionable insights. Also, it must support features regarding connect, monitor and control (bi- directional communications). It must serve as a single source of truth for various stakeholders, transformation data into smart data and gaining actionable insights. In detail it must leverage collecting and monitoring data to detect incidents, conditions monitoring, alarm notifications, early warning system. It must allow creating of dashboard for all ingested data and leverage AI and machine learning to proactively identify warnings and automatically prompt real-time action to manage and resolve incidents. KPI, libraries, threshold, rules can be configured arbitrarily. Historical analysis (trend data in verity of charts types) and deep analysis of various data points across use cases and visually correlating of the data must be easily achieved. A mapping between use case and locations (in 3D or 2D model) is requested. Next to the data itself, also data source’s structure must be visualized in physical topologies.

2. The platform should enable both business and IT to actively participate in the innovation process. Leveraging a single platform and model, the platform should enable collaboration between all stakeholders and offer purpose-built tools for people with different skill sets:

▪ No Code tools for users on the business side (“excel power users”) who may not know how to code but have strong knowledge about a process or specific domain.

▪ Low-Code tools for domain experts who are slightly more technical but may not know how to code. ▪ And tools for pro / full stack developers who want to have maximum control or who need to enrich low

code apps with their custom code.

3.2 Technical requirements

Nowadays technically nearly everything is possible if there is enough time, endurance, and budget. Everything can be implemented if detailed requirements are given and if there are enough resources to drive the development or high customization.

InJo4.0 is not striving for such an approach and is instead searching for an IoT platform that already comes with an outstanding maturity (meaning that most details are already taken care of) and where all required core features are already implemented without the need for coding or customizing.

All requirements/core features must be represented through a clear and consistent UI enabling all users with organizational experience to directly start using the platform and through backend APIs (enabling a fully automated management through batch jobs or event-based). InJo4.0 is asking for detailed information regarding each of the following functional and non-functional requirements. Technical requirements for the implemented project include the following topics for each of which the tenderer must provide a written concept. The listed requirements are mandatory but non-exhaustive, so also additional information on the chapters can be provided.

3.2.1 platform capabilities

The Industrial IoT application platform should deliver a highly scalable, fully integrated set of capabilities that enable consumers to achieve complete digital transformation, certain aspects of performance, scale, reliability, and security are critical to customer success. There should be no need to worry about partitioning, high throughput pipelines, real-time processing, optimized storage, data isolation, and sharing, or operations and management of the software components. The solutions that leverage the platform capabilities. Providing customers, a common view into all data that is stored, processed and accessed through these building blocks.

3.2.2 platform Architecture

The primary components of the platform are the Server and the Edge. The Server handles user and device authentication, brokers communication between systems, people, and things in the solution landscape, and handles data transformation, data persistence, and business logic, as necessary, for the end-user application. The Edge enables devices to securely communicate to the server and be full participants in the solution landscape. The platform architecture can be represented in a simple and common software layered pattern where services and components are organized in layers. The layers of modularity and components are typically meant to show that all the components are interconnected but do not necessarily depend on each other. The multiple layers represent the applications, data, integration, and external systems.

3.2.3 Scalability

the platform should be designed with proven scalable web technologies and with uptime and availability in mind. And ultimately unlimited in capacity across all aspects – including devices, documents, and users – due to the flexible federated server architecture that provides for API Connection servers, Platform servers, and Data Storage servers. A single Platform server has been tested to handle >1M entities with 10-12 Connection servers handling the user and device API interaction across their respective duty cycles. The data volume of the system is limited only by the disk storage capacity and our data storage model can handle >30k transactions per second per Storage server.

3.2.4 Connectivity Typical features of field agents are:

• Visualizations, analytics, and augmented reality experiences using plant floor data made possible within minutes via platform integration.

• IoT-ready, with interfaces to on-premises web servers and off-premises cloud applications for real-time insight into industrial operations.

• Compatible with leading hypervisors like VMware and Hyper-V for deployment on public and private clouds.

• Enhanced messaging security via SSL and TLS for secure, authenticated, and encrypted communications across various network topologies to meet site security requirements.

• Multiple redundancy options ensure resiliency, high reliability, and uptime in critical applications.

• Facilitating communication with legacy or non-internet connected devices, Data caching,

• buffering and streaming, Data pre-processing, cleansing, filtering, and optimization

• Data aggregation, Device-to-Device communications/M2M, short term data historian (e.g., using ring buffers)

• Security – manage user access and audit log, device configuration management

• Diagnostics, offline services, and real-time control of devices translates protocols

• Encryption, local decision making, and Edge Analytics.

• Streamlined interface for simple installation, configuration, maintenance, and troubleshooting Typical connectivity sources are:

• PLCs, SCADA, DCS Systems, Databases, File System, Web Servers, Message Brokers & Devices

• IoT-Gateways (LoRaWAN, nWave, Sigfox), Edge-Agents Typical protocols to be supported:

• OPC UA, OPC DA, Modbus-TCP, BACnet, MQTT/S, HTTP/S, ODBC/JDBC and FTP/SFTP, REST APIs, OPC HDA, OPC .NET, SNMP, AlwaysOn, Splunk Industrial Data Forwarder.

• Supporting hassle-free device onboarding, supporting flexible asset modeling, operating system independent, IoT Agent High availability enabled, secured communication, Bi-directional communication, autonomous, adaptable to any proprietary protocols, and persistent.

• Connectivity to devices is enabled via several methods (Direct network connections, Third-party device clouds, Open APIs).

• A scalable, secure, and easily deployable communication technology designed for providing continuous bi-directional connectivity between sensors, devices, equipment, and the server.

3.2.5 Onboarding and managing of users All users can be managed through groups. The groups can be stacked freely (i.e., groups can be part of other groups, the same user can be in two groups). users can be invited to add a valid email address.

3.2.6 Data governance and rights for applications/users All data in the platform can be accessed, modified, and deleted by the customer at any point in time and the customer will always be the single owner of all data ingested in the platform. And the following features are to be available:

• Control user access to the server, data source, or data values .

• Regulate read/write access .

• Provide the ability to disconnect client applications .

• Support the configuration of secure data tunnels.

3.2.7 Monitoring and Events/Notifications The platform needs to provide ready-to-use APIs which enable notification via Email, Push-Notification or SMS. The platform must support the ability to set automatically triggered alerts in the system monitoring and management tool through the selection of required metrics and custom user-defined thresholds.

3.2.8 Data Model

The platform needs to provide an existing data model framework, that provides clear a path to how assets/devices (referred to as "devices") need to be modeled. Developers must be in the position to just use it with existing APIs and without the need for the creation of any custom relational or non-relational databases or custom code to expose that kind of data model. The data model APIs must cover CRUD operations for the devices (also supporting relations to each other), for the variables in the context of those devices, for time series data for those variables, and files and events related to the devices. Events, time-series data, and files need to be intrinsically linked to the devices.

3.2.9 Data Sharing The platform should be able to share data from an external system (e.g., PLM, MFG, ERP…) into the platform to perform analytics or build applications that combine data from multiple sources. Data stored in the data lake can be shared with 3rd party and cloud-native tools. Direct access to the data lake can be granted using a combination of platform data access controls and is enforced by IAM policies. This enables a secure mechanism to leverage.

3.2.10 Data analytics In general, each use case will be providing analytics/reporting data with information specific and tailored to the use case. The IoT platform must provide a toolset to process and store this data with the goal that central reporting with standard platform tools is available. The actual algorithms/models will either be provided by the use-case or even being created during the use-case implementation. They must be continuously improved during operation. The IoT platform must offer APIs for standard analytics operation (e.g., trend prediction, anomaly detection, signal validation, signal calculation, aggregates building, flexible KPI calculation, and spectrum analysis) and a fully integrated.

platform Analytics uses sophisticated artificial intelligence and machine learning technology to tackle the specific challenges presented by industrial IoT data. Through automation, Analytics delivers reliable, actionable insights in real-time to applications. platform Analytics is designed to simplify and automate the complex analytical process for IIoT solution developers that may not have expertise in data modeling, complex mathematics, statistical analysis, artificial intelligence, or machine learning.

3.2.11 Edge applications and edge device management The Edge is a small piece of software that enables our customers to enable their remote “edge” devices, sensors, and systems easily and flexibly to fully participate in Connected Applications. The edge enables the Platform to transparently access through firewalls the data, events, and services provided by remote devices and allows remote devices transparent access to the data, events, and services running on the platform. The edge can be embedded directly into an edge device, run in gateway devices that sit in front of one or more remote entities, or run on a standard computer operating with Windows or Linux. In addition, the edge capabilities also exist in Software Development Kits (SDK) in a variety of languages (Java, .NET, C, Python). Edge app lifecycle management must be fully supported through cloud-based edge application registries and standard distribution mechanisms to drive any kind of edge data acquisition, edge data preprocessing, and edge data analytics. The platform must offer support for dedicated industrial edge devices but also support any kind of hardware-independent open edge devices (e.g., an arbitrary VM or physical machine running Windows or Linux with or without docker). On top of standard edge-management capabilities, a framework for the convenient deployment of machine learning models including KPI-based command and control redistribution needs to be presented. The following features are to be supported from the platform:

• Edge Device Monitoring

• Edge Device Configuration

• Edge Device Diagnostic

• Edge Device Software/Firmware Management

• Edge Device Connectivity Monitoring

• Edge Application Visualization

• Edge Device Mass Software Update

• Edge Alert Monitoring, Real-time/Historic/ Acknowledgement.

3.2.12 Standard applications for data processing and visualization

The platform must natively fully support the data model through the existing APIs and allow the creation and sharing of any dashboards based on that raw data. Data can be pre/post-processed through flow-based applications supporting drag and drop user interface (such as Node-RED or similar ). Custom-created KPI can be defined and published for user groups. For the visualization raw and processed data, as well as defined KPIs, are accessible. These tools shall be in system: Event Chart, Grid, Label Chart, Pie Chart, Progressive Gauge, Proportional Chart, Range Chart, Tag Cloud, Time Series Chart, and XY Chart, X-axis label, Bubble chart, and LED label, that can be used in the dashboard’s builder for purposes of data visualization. Also, the platform should provide a set of base operators (filter, time window, query, and filtering) that may be applied to datasets, and given the open and extensible architecture adding additional operators is supported.

3.2.13 Remote field service management

The platform must come with an application that enables service technicians to allow convenient remote access to perform remote services (including work-order management and automated assignment), connections to connected devices via popular remote access tools such as remote desktop or SSH, VNC.

3.2.14 Service-Usage Transparency

The platform needs to provide a transparent overview stating exactly which users/apps are using which services for each of the tenants in place. All tenant users/contributors need to be able to see their consumptions.

3.2.15 Data Request Scheduling

The Scheduler advanced plug-in for Connectivity enables users to move the scheduling of data requests from the client to the server to optimize client communications across networks with limited bandwidth. It can define polling schedules for specific tags from multiple devices by the time of day or frequency. It also enables users to define exceptions for periods of time when polling is undesirable. Each schedule can be configured with its priority to determine which schedule is serviced first when a conflict arises; the server will update clients with data once it is available.

3.2.16 Digital Twin (Optional)

The platform can represent the Model/product, to create a true Digital Twin of a physical product. The Platform must extend the idea of a digital twin to include everything about the asset, from CAD/PLM to manufacturing to service state. These can all be represented and consumed in the application. Platform to be used to create a digital twin representation for applications and analytics to interact with, abstracting the details of connectivity and the nuances of machine specifics so that upstream business systems have an elegant API and associated set of advanced tools by which to build and evolve the solution.

3.2.17 Security

The platform should be a very secure solution through controls such as:

• Extremely flexible permissions & visibility capabilities including Access Control Lists

• Design & run-time permissions down to the Property level

• Visibility modeled based on organizational structure

• Robust user and group management

• Integration with Active Directory and Single Sign-on frameworks

• TLS encryption

• Full audit trail of all actions in the development environment.

• the platform provides for full authentication, authorization, and group/role-based access control. grained access control allows customers to constrain both reading and writing permissions down to the property/service level, not just at the device level.

• Allow the system to manage password policies such as password expiration and password strength.

• Password reset option when creating a new user in the system. If the password reset option is chosen for a user inside the organization, that user would see a button for resetting their password on their profile.

• Administrators can configure their own account lockout settings such as (Maximum Login Attempts, Minutes to Attempt Login, Minutes Locked Out)

• Device Identity; provides the use of App Keys for Device Identity

• logging system built into the platform.

• The platform should support different versions and features of Encryption: Transport Layer Security (TLS) protocol to provide secure connections and encrypt data-in-motion, or Secure Sockets Layer (SSL) protocol.

3.3 Integration requirements

• The platform must offer different approaches to integrate data from existing on-premises or cloud-based IT systems. Those integration methods must support scheduled batch synchronization and event-driven synchronization and event-driven triggers. For any kind of integration reusable components must be provided to drive an enhanced user experience and full transparency of data from different related tools/sources. Straight forward extensibility enables an easy expansion into higher solution value by leveraging additional plugins/applications.

• The requests to self-hosted applications accessed this way will be enriched with security- headers by the platform's gateway.

• the platform must also support integrating with the custom identity provider and custom data analytics tools. The platform’s APIs must provide a comprehensible integration with any other applications/systems. Interoperability between O-Data and OpenAPI specifications must be ensured.

3.4 Non-functional Requirements • The tenderer must explain based on different disaster scenarios, how actual disaster recovery and business

continuity are achieved in detail. The amount and characteristics of those scenarios can be chosen freely but they must fit the already planned use-cases. Since many use-cases are based on field-level data, also approaches must be described on how to ensure business continuity at the field level.

• The platform must be able to be deployed in the context of a cloud provider (e.g., AWS, Azure …) as well as in a local

container application platform (e.g., OpenShift running within a local datacenter). The platform must be able to scale up based on the number of devices and workload.

• The training must enable customer’s users to work with the platform and to leverage the existing features described in the concepts (e.g., how to use the low-coding capabilities, how to implement new KPIs, how to set up a new data analytics model, how to onboard new edge-devices or field devices, how to create new device-blueprints …). There must be various training offerings for different kinds of user foreknowledge including at least offerings like standard classrooms training, virtual-led training, and customized on-site training.

• The platform shall operate remotely. The tenderer needs to specify which remote access to the operating

environment and relevant systems is needed for the execution of his services. The customer needs to provide

this access.

4 ADMINISTRATIVE INFORMATION

• Administration cycle: 1. RFP released on 12- Oct 2021. 2. Question deadline is 19 - Oct 2021. 3. Publish the Q&A on 24 - Oct 2021. 4. Submitting proposal deadline is 12- Nov 2021 @ 4:00 pm Jordan Time.

• question:

should be submitted to SAMProc@samengineering.com WITH Email subject set as: 1. For Question: InJo4.0 | [Bidder Name] | Questions

• Proposal: Should be send to the below address Jordan – Amman - Abdullah Ghosheh St. Building # 75 PO Box: 142470 Amman 11844 | Jordan Attention to: Layalee Abu Ali Two closed envelops for technical and financial submission packages. Proposals should be submitted to the designated address above by the date and time of the deadline provided above.

5 Submission packages a. Envelope 1:

1. Compliance Sheet. 2. Technical proposal. 3. License model description, upgrade add-on available and description (without providing the pricing)

The proposal will be excluded, If the bidder provides the prices of the licenses in technical envelope. 4. Support and maintenance plans 5. Training methodology, topics, training tools (access to the training environment such as Labs, sandbox and projects)

recognized certificate, Pre & post skills assessment tools, Pre-requisites skills In addition to any added value information.

6. References. 7. Sample of the applications published in the provider marketplace. 8. proof of nationality under their national legislation.

b. Envelop 2 1. Financial offer.

For digital Service Objective: a. Provide detailed pricing for the basic License in addition to the available Add-on for upgrade purposes. b. provide the price for the below scenarios, in addition to clarification on the calculation basis.

Note: in case the attribute mentioned in the table does not consider as factor in the pricing, then leave empty. c. Provide the calculation for both SaaS and On-Premises options.

Attribute Scenario 1 Scenario 2 Scenario 3

# Of asset 200 3000 40000

# Of asset Type 20 100 100

# Of clients/End Users (App Service)

20 30 40

# Of users for each client

2 3 3

Real Time Storage per client/Yearly

200 GB 300 GB 400 GB

RAM Per App (Including Analytics)

2 GB 2 GB 2 GB

Time Series Date Rate(for all End use)

10 KB/s 100 KB/s 100 KB/s

Analytics tools (BI) should be available for each scenario and for each end user. AI & ML tools can be added as optional items to each scenario. For ICT Objective: a. Development access license per ICT company. b. Marketplace publishing fees. c. Upgrade Add-ons.

For Training: a. Training cost for the 15 participants.

6 EVALUATION METHODOLOGY AND CRITERIA

Preliminary Evaluation The preliminary evaluation is done to determine whether the offers meet the administrative requirements and Eligibility Criteria of the RFP.

Best price-quality ratio methodology: A two-stage procedure will be utilized in evaluating of the proposals; the technical proposal will be evaluated with a minimum pass requirement of 70% of the obtainable 70 points. A proposal shall be rejected at this stage if it fails to achieve the minimum technical threshold of 70% of the total obtainable score of 70 points prior to any price proposal being opened and compared. The financial proposal will be opened only for those bidders whose technical proposal achieved the minimum technical threshold and are determined to be compliant. Non- compliant proposals will not be eligible for further consideration. The evaluation of the proposals will consider the best price-quality ratio and will be carried out by the project management team, considering 60% for the commercial offer and 40% for the technical offer, according to the following formula:

S = (St x T %) + (SF x P %)

Where: T: Technical Weight P: Commercial Weight St: Technical mark presented as 100 x Tc/Tm SF: Commercial mark presented as 100 x FL/F Tc: Technical mark under consideration Tm: The highest technical mark among offers FL: The lowest price offer F: The Price of the offer under consideration

Evaluation of technical proposal: The technical proposal is evaluated and examined to determine its responsiveness and compliancy with the requirements specified in this solicitation documents. The quality of each technical proposal will be evaluated in accordance with the following technical evaluation criteria and the associated weighting (total possible value of [70] points):

1 Compliance with the technical requirements 30

2 Marketplace applications Availability and diversity 10

3 Clarity, flexibility, and expandability of the license model 20

4 The platform offering at least meet one of global objectives. 20

5 Provide SaaS and On-Premises licensing 20