IoT SMART PLATFORM

USERGUIDE

1. INTRODUCTION

IoT SmartPlatform means the set of application modules and infrastructure technologies designed and developed with the aim of guaranteeing the delivery in cloud mode of advanced services within the framework of SmartCity to define new operating standards in construction and the delivery of smart services.
IoT SmartPlatform is a homogeneous and coordinated ecosystem of software components developed at microservices that, starting from the excellence of the available technology, overcomes its limits through an incessant research and development activity to define new operating standards in the construction and supply of smart services.

2. IoT SMART PLATFORM: THE CONCEPTUAL MODEL

Designing and implementing effective and efficient IoT solutions requires a completely redesigned information management platform compared to the standard paradigms of common Enterprise services.

2.Iot-Smartplatform-Il-Modello-Concettuale_ENG

2.1 SmartNetwork and Big-Data Storage: Ability to collect, store and manage data/measurements.

To project reality into its digital representation, it is necessary to design and implement a network of sensors that are able to measure reality in its multiple dimensions that define its behaviour, and guarantee a robust, simple and effective system to convey this data to a processing centre. IoT Smart Platfom is able to accommodate the data collected by Smartnetwork, monitor its status in a proactive way and ensure a single management point for a wireless network extended as desired and consisting of a heterogeneous set of sensors that are also pre-existing because past investments are the starting point for the adoption of smart solutions. The data coming from reality, as measured by the sensors distributed on a large scale, are by their very nature very variable and can reach very quickly and for every single case of use volumes that are absolutely important and not manageable with common database engines. IoT Smart Platform sees at its foundation a mature mastery of Big-Data technologies and a robust and highly performing architecture of data collection, persistence and recovery. In IoT Smart Platform we adopt the term “measures” that covers not only the given row measured in the field, but also the data derived from its processing, and we adopt the term “snapshot” for all the messages of coordination control and implementation that are exchanged with the outside world and between the modules of the platform itself.

Before managing the information, it is important to be ready to memorise it correctly without having to bend your requirements to the technological limits of traditional relational technologies.

2.2 Virtual sensors and historical series: Ability to process data and summarise information.

Having large amounts of data available is as fundamental as having the ability to extract from them a set of trends, consistent measurements, and useful and meaningful aggregates.

Smart Platform extends the pure functionality of persistence and data recovery by performing real-time transformation and integration operations or subsequent reduction operations on the data itself according to the specific needs of the case of use analysed.

The necessary stream-computing and data interpolation technologies were then integrated into the platform, based on mathematical models for the development of the quantities considered by extracting second-level measures that represent the distillate that is useful for the various use cases that you want to implement. This level of processing is mainly covered by virtual sensors that are concerned with applying models to the measured discrete data by returning validated, reliable data with high information content, ensuring an effective monitoring activity.

2.3 Functional sensors and states: Ability to assign a status to a system, and perform simulations and diagnostics.

A system, to be managed, requires expected and optimised models to develop it so that it can define any corrective actions to achieve convergence between real development and theoretical optimisation. When it comes to complex systems (for example in the Energy context) or complex use cases (such as in the Safety context), it is a good idea to have a platform capable of restoring a system status that is not only consistent, but also understandable to those who control the system and the specific process. IoT Smart Platform integrates the most advanced technologies of probabilistic data analysis through the use of libraries at runtime that implement Bayesian logic, thus ensuring the possibility of having a simplified view of the system by minimising the variables to be monitored and discriminating against the significant ones from the second order.

IoT Smart Platform also uses the level of the functional sensors to allow the simulation and diagnostic activities of the systems, enabling the insertion in the particular system’s model of behaviour of the simulated measures at multiple levels, by being able to highlight with extreme effectiveness what they would imply and what could be generated.

A functional sensor is the result of a domain engineering activity (energy, environmental, construction, etc.), and at the same time is the result of modelling the system as well as being its instrument of control.

2.4 Monitoring and Widgets: Manage, Act and React.

Having a reliable system status available, you can model SCADA interfaces to define the setpoints and the desired alarms. At the same time, automatic reactions can be defined for the occurrence of certain states of the system, in order to react automatically and implement smart solutions. IoT Smart Platform allows you to extend your standard set of user widgets to adapt to the specific needs of the manager, as well as to extend the monitoring libraries so that all implementations are performed, which is feedback that a multidisciplinary approach to the complex IoT world can allow. The same sensors can be considered in different contexts, optimising the design needs by refining and raising the specific effectiveness of the system as a whole.

2.5 Bundles: Vertical use cases ready.

Being able to have the technology to define and configure complex realities with pervasive adoption of IoT technologies, it is essential to summarise pre-configured vertical use cases that simplify the complexity of the system by exposing the user to easily understandable and directly usable packages guiding the configuration and deployment steps.

Through the use of the Bayesian network editor of the Hugin library, it is possible to extend the functional models that can be used in the IoT Smart Platform

3. OVERVIEW

The IoT Smart Platform consists of some modules called “cores” that form the basic core, and other additional modules that have been designed and built to extend the functionality of the system both in terms of integration and functional coverage.

3.1 Big-Data Storage

The IoT Smart Platform integrates the most up-to-date infrastructure and application solutions for collecting, storing and querying data collected by distributed sensors. The strategic choice is to start from a robust and consolidated ecosystem of open source tools and to integrate it with the extensions necessary for the correct processing of data as expected by the IoT.

3.2 Virtual Sensors, Functions, Monitoring

The IoT Smart Platform guarantees full coverage of use cases of both continuous monitoring and implementation and management of systems thanks to the adoption of the most up-to-date technologies for the modelling and probabilistic processing of data.

3.2.1 Virtual sensors: Interpolation of digital data with the application of development models.

The data measured by the sensors are digital and therefore discrete in time and values, to return to them an analogical trend behaviour linked to the development model of the measured quantity.

A library of mathematical models has been integrated with the state of the art Labview that guarantees the full availability of all the necessary mathematical functions, as well as constituting a common development substratum open to any contributions to the modelling carried out by partners and reusable in the platform itself. The only attention to be taken is in the form of the generated libraries and the inclusion of the communication interfaces with the SmartPlatform channels.

A Smart Platform virtual sensor can always be queried independently of the reference Timestamp, and measurement data will be returned with its probabilistic reliability that depends on the availability of physical data to support the development model being considered, eliminating from the SmartPlatform solutions the need to have physical measurements synchronised to have comparable data on the time scale.

The system allows to extend the library of virtual sensors to compose the data coming from one or more measurements and to apply models of evolution and calculation of the reliability of the calculated data with temporal or other decline. Through the LabVIEW math library editor, it is possible to define new custom virtual sensors ready for use in SmartPlatform, the WebService Request , Trial MQTT Payload Parser and Token blocks are provided for connection to the MQTT Platform Broker.

3.2.2 FUNCTIONAL SENSORS: Summary of the system status

In the IoT Smart Platform, the validated data generated by the functional sensors are input variables of Bayesian probabilistic networks that describe the behaviour of the system allowing a simplification of the variables to be considered and enabling a by-design modelling superior to any management system based on rules.

We have integrated the use of a standard Hugin library at runtime, which is, in analogy to virtual sensors, a platform of developments for partners who want to adopt the IoT Smart Platform enriching it with their own management know-how and domain modelling engineering.

The network nodes are defined, the probabilities are assigned and then the inference analysis is performed using the simulation tool to diagnose the network before it is added to the library.

3.2.3 Monitor and CEP Action and Reaction.

The system allows modelling of a reactive behaviour and proactive monitoring of the measured quantities and states of the modelled system. The IoT Smart Platform provides a set of standard libraries for the management of sensors and some of the analysed use cases. Like the other levels of the platform, the monitoring libraries can also be enriched by proprietary logics developed by partners. It is possible to define complex monitoring rules based on drool language that use a specific syntax for their use for the definition of facts and actions through Complex Event Processing (CEP) nodes, expressly provided to meet this need.

Ex.

import it.filippetti.sp.snapshot.Snapshot

import it.filippetti.sp.snapshot.IMeasurement

import java.util.List import java.net.URI

import it.filippetti.sp.snapshot.Measurement import it.filippetti.sp.snapshot.Relation

import it.filippetti.IoT SmartPlatform.monitor.cep.events.SnapshotEvent import it.filippetti.IoT SmartPlatform.monitor.cep.events.TickEvent

global it.filippetti.IoT SmartPlatform.monitor.task.CepTask engine;

declare SnapshotEvent @role(event) @timestamp(timestamp)

End

 

declare TickEvent @role(event)

end

 

declare window GateEvents

SnapshotEvent( category == “gate”, context != “sync” ) over window:time( 1m1s )

end

rule “Debug Mqtt Message” when

$s : SnapshotEvent() then

engine.logEvent( “” + $s ); end

3.2.3 Monitor and CEP: Action and Reaction

The whole platform is structured by-design for the multitenant management of data and accesses, the authentication protocols adopted are the standard for IoT solutions: Saml and OAUT2. A complete ACL system on the individual data streams and on the navigation menus of the user interface, allow a punctual controlled access to the data and a user experience that is contextualised to one’s role.

4. USER INTERFACE

Fully developed in html5, css and jvascript allows access to the smartplatform functionality by consuming the system APIs for authentication, data recovery in real time and time series as well as alarms, events, warnings.

It provides a central work area in which the data and events are reported in a geolocalized form, a tab in which the contextual widgets are accessed for the scope and use case and a further tab for the in-depth analysis of the historical series.

5. ASSET MANAGEMENT AND BIM

IoT SmartPlatform integrates a complete set of solutions for traditional asset management both in terms of documentation and maintenance plans. The same tool allows the management of complex objects such as editable floor plans, tagged orthophotos and point clouds obtained from laser scanner or other processing.

Please refer to specific documentation for the description of the integrated management modules.

It is therefore possible to integrate the traditional management tool with the monitoring part in real time in a single solution, enabling a perfect implementation of the 4.0 Enterprise tools, in which, for example, the maintenance of a piece of equipment is not linked to an estimate of the time average of utilisation, but its actual time of utilisation.

With the support of BIM formats, IoT SmartPlatform is now able to incorporate information on plants and structures included in the design phase and make them the object of continuous monitoring.

6. SUPPORTS  RFID SENSORS

In addition to activating sensors, the IoT Smart Platform also includes a complete module for the management of passive RFID sensors that cannot be renounced in logistics and traceability of goods and commodities where the price of the RFID sensor is a discriminating factor based on the volumes involved.

Please refer to specific documentation for the description of the detection devices, supported tags and functionality of the integrated management module.

It is therefore possible to integrate the traditional management tool with the monitoring part in real time in a single solution, enabling a perfect implementation of the 4.0 Enterprise tools, in which, for example, the maintenance of an equipment is not linked to an estimate of the average time of use but to its effective time of use.

With the support of BIM formats, IoT SmartPlatform is now able to incorporate information on plants and structures included in the design phase and make them the object of continuous monitoring.

7. INTEGRATION INTERFACE WITH THE IoT SMART PLATFORM

The IoT Smart Platform consists of some modules called “cores” that form the basic core, and other additional modules that have been designed and built to extend the functionality of the system both in terms of integration and functional coverage.

7.1 Broker MQTT Authenticated

In the context just described, one of the main technologies behind the IoT Smart Platform is the support for the IoT communication protocols of the Machine2Machine type (M2M). In particular, the IoT Smart Platform adopts MQTT as an open standard protocol to support integration in Smart Cities.

MQTT is the acronym for MQ Telemetry Transport. It is a very simple and lightweight publish / subscribe messaging protocol designed for networks that have limited bandwidth, high latency time and / or are not very reliable. The design principles for the protocol are minimising bandwidth consumption while still guaranteeing reliability in data delivery.

7.2 SmartDevice: the standard IoT Smart Platform device

Based on the experience of sensor integration fields, we have defined the best set of information that we expect to be contained in a Json message for the IoT and we called it SmartDevice.

The message exchange models within the IoT SmartPlatform are based on the use of JSON payloads that describe measurement models coming from the SmartNetwork. These models are exchanged through use of the MQTT protocol where:

  • The topic uniquely identifies a sensor inside the SmartNetwork
  • The payload contains the JSON format message relating to the snapshot of the sensor measurements at the time of measurement.

The entity described above is generated within the SmartNetwork and published on the MQTT broker in order to be made available to the other components of the platform (Big Data storage, real-time analysis components, monitoring and reporting interfaces).

7.3 PayLoad SmartDevice

Any sensor or actuator device that wishes to be natively compatible with IoT SmartPlatform must banally generate messages in this format and be able to forward them through the MQTT protocol to our broker.

For devices that do not have to be adaptable, we have integrated the “Mediator” module, which takes care of mediating / converting messages that arrive in another known format  into the native SmartDevice format.

{

“T”: unix communication timestamp (inclusive of milliseconds), “m”: [

{

“K”: the code name of the measure,

“t”: unix timestamp of the measure (inclusive of milliseconds),

“V”: measured value, “u”: unit of measure

},

],

“Ref”: uri  unique of the sensor at the interior of the SmartNetwork, “type”: mnemonic name of the sensor type

}

7.4 API Rest

IoT Smart Platform supports the Http Rest communication protocol as an access point to the integration API (with other applications) and in general between the various modules of the IoTSmart Platform itself.

There are a number of Rest APIs available to integrate IoT Smart Platform technology into other existing partner solutions.

7.4.1 Smart-is

Access to the authentication system for the recovery of the necessary OAut2 token.

7.4.2 Smart-config

Authenticated access to the “registry” of the IoT Smart Platform to recover the configuration of the System and the triggering / check / actuate logics implemented for the use cases of the various tenants.

7.4.3 Smart-dataservice

Authenticated access to IoT Smart Platform data persistence and retrieval services to retrieve time series and data generated by the IoT Smart Platfom in the Big-Data Store module.

7.5 SDK

It is available in both “Java” and “.Net” versions and constitutes a complete integration library that wraps the Rest API and the Parsers of the SmartDevice format, allowing a fast adoption of the IoT Smart Platform technology in other software projects and making the basic technologies illustrated above transparent to the developer.

8. IoT SMART PLATFORM TECHNOLOGICAL ECOSYSTEM

IoT SmartPlatform uses in its modules the de facto standard of available technology, below is a list of programming languages and architectural solutions used

  • Open (Java, html5, css, jscript, S.O. linux)
  • Secure (Saml – OAuth2, centralised identity provider for UI, API Rest and MQTT)
  • Multitenant (integrates by design multitenancy and data isolation)
  • Standard (language, protocols, integration patterns) Rest, MQTT, AMQP, OGC, SOA
  • Cloud-ready (docker Container, self contained independent modules, micro service architecture, API Rest, http/https)
  • Enterprise class (Vertical & horizontal scalability, ESB, HA Ready, Hadoop, EDMS : Alfresco + Activiti, Rule Engine, )
  • Extensible (definition of module interfaces that can be developed by partners & plugged-in, integrated with Industrial Electronic devices Modbus, EtherNet-IP, TwinCat )
  • Robust (integrated IaaS real time monitoring, HA proxy and clusters )
  • Simple (Configuration drawing graphs, widgets, bundles in solution marketplace for a quick deploy, wizard)

9. IoT SMART PLATFORM DELIVERY ARCHITECTURE

IoT SmartPlatform is supplied today by Datacenter Filippetti, the computational resources are guaranteed by the VMWare virtualisation layer and the system for monitoring physical and virtual systems is integrated with the centralised system for the provision of Outsourcing / OutTasking services of the group based on  Foglight technology. The use in the design phase of the microservice paradigm allows to easily act with corrective and evolutionary maintenance on the components of the system guaranteeing to the final customers the maximum availability of the service and at the same time a continuous evolution of the system without the efforts and the impacts of the updates that they are traditionally used in monolithic applications.

The use of container technologies through the Docker solution allows the maximum dynamism of the supply and the updating of the microservices themselves including their possible relocation and deployment on different delivery servers also distributed on a geographical scale. A first area of the infrastructure houses the business logic, the back-office services and the interfaces with the user and the sensor network, a second area is dedicated to historicising data and measures, to their reduction and provision of real time reduction.

9.Architettura-erogazione-IoT-SmartPlatform

10. MONITORING SYSTEM

Within the framework of the IoT Smart Platform service, an environment is defined for monitoring the good functioning of the technology infrastructure and the components described above. The solution identified for these IT monitoring needs and user activity analysis is based on Dell Software’s Foglight platform. The Foglight platform is a solution that is part of the APM context or Application Performance Monitoring. Foglight is able to provide the functions of monitoring the health of the systems and to analyse the application performance perceived by end users (internal and external) delineating the critical path between the user and the IT resources used. In case of anomalies, the end to end design of the dependencies between systems, allows the rapid and effective diagnosis of the problems and their causes.

The solution has among its strengths the modular approach that makes it easily adaptable to changes that the IT context of the Association will undergo over time. The flexibility and ability to monitor and analyse heterogeneous environments is combined with the ability to aggregate and standardise metrics from IT systems under homogeneous viewpoints. These points of view are represented by “out-of-the-box” web dashboards that can be consulted by the user using the most popular browsers without any external requirements (e.g. plug-ins). The modules (cartridges) enable the depth and quality of sampled metrics, extracted from the target monitoring systems, to be adapted for each environment. Foglight can therefore use different methods of querying the monitored systems, privileging remote access to avoid the installation of agent on monitored systems.

Access to the systems is done using protocols unique to each technology, purely by way of example: SSH for Linux / Unix, WMI or WinRM for Windows, HTTPS for webserver or vSphere, JDBC for RDBMS, etc. The minimum requirement will therefore be the availability of a user, defined on the target system, to be used for remote queries.

Completing the monitoring instrumentation is an installation of Zabbix for the monitoring of specific backoffice processes and the diagnostics of the networking part.

11. INFRASTRUCTURAL REQUIREMENTS

This section describes the HW and SW requirements to be able to use the IoT SmartPlatform based solutions. The IoT SmartPlatform service is provided by IDC Filippetti.

All possible connections that may be necessary from the customer’s network to the service centre will be realised in the Lan2Lan point-to-point VPN mode. All the usability addresses of the system to which users can be connected will be delivered on a secure and protected protocol of the type https / tls. It is not intended to install specific browser plug-ins or specific software on the users’ client. The solution is browser independent and certified for the most common browsers currently available, according to the browser compatibility matrix.

Browser Supported Non supported
Internet Explorer 11 X
Internet Explorer 10 X
Internet Explorer 9 o inf. X
Google Chrome (ultima versione rilasciata) X
Mozilla Firefox (ultima versione rilasciata) X
Apple Safari (ultima versione rilasciata) X

12.COMPONENTS AND Service Level Agreement (SLA)

IoT Smart Platform is a PaaS service provided by IDC of the Filippetti Group and is offered upon subscription for a fee.

The IoT Smart Platform fee is divided mainly into 3 components

C.1 a first component that regards the availability of the Infrastructural platform and that depends fundamentally on the number of data sources in ingest (band) and the retention period that the customer or specific solution requires.

The C1 service component includes:

the band entering and leaving DataCenter up to 2Mbit/s (guaranteed 500Kb/s) for each tenant;

sufficient storage space for storing platform data for the agreed period, proactive system monitoring service;

high reliability of the servers, backup copies and availability of the service equal to 99.9% of the useful time.

C.2  a second component regards the availability of the Application platform and depends on the complexity of the solution to be managed estimated on the basis of the growing smartness processing paradigm: Physical, Virtual and Functional. Usually the number of physical sources multiplied by the factor 3 is considered.

The C2 service component includes:

creation of a tenant on shared architecture;

ingest infrastructure with a performance of 1,000,000 messages per day with Near Real Time performance;

access to the platform through the standard user interface and use of the widgets available, the system provides concurrent access to up to 20 competitors for tenants with the possibility of increasing on a design basis up to even thousands of simultaneous accesses;

availability of integration API in http format for the use of IoT SmartPlatform data and messages in other applications;

availability of a library of pre-defined virtual and functional sensors for the implementation of the various use cases; identity provider and ESB with high capacity and availability for secure authentication of system users and possible delegation to external systems, integration with legacy systems through available plug-ins; Integration with  ECM systems and BPM  standard through the use of CMIS protocols and standard BPMN2, on a project basis the provision of an instance of ECM Alfresco and of the Workflow Engine Activiti is planned; proactive monitoring of the sensors that are the object of the solution;

Complete system of configuration and monitoring of the implemented use case including the availability of data sent to a specific instance of relational database for reporting; Multi-channel SMS / Mail messaging for sending alarms or events;

Library of pre-configured solutions bundles for rapid adoption of use cases such as:

>  monitoring of electrical panels

>  monitoring personal security equipment

>  monitoring the correct use of devices such as masks and helmets

>  monitoring and control of lighting installations based on brightness, presence and time

> monitoring and access control

> man monitoring on the ground

 

C.3 a third component concerns the availability of the assistance service to support the configuration and use of the platform.

The service guarantees a single point of contact for the end customer for any problem that occurs in the use of the platform itself.

12.1 Virtual Appliance

This paragraph proposes to provide a description of the service fee in the case of the provision of the same on the infrastructural platform provided by the customer. This delivery method is called Virtual Appliance as it is planned to deliver the platform itself in the form of pre-configured and installed virtual machines. Virtual appliance exhibits a more limited set of features as described.

The service includes the limited persistence of files and calculated data,  NOT supported and included is multi-tenancy, proactive monitoring, API REST, analysis and predictive feedback based on trends and the updated library of available  solutions ready for rapid deployment ( Bundles).

The component of the C2 fee is therefore modified in the C2VA contents as follows:

C.2VA fee component regarding the license to use the Application platform provided by the infrastructure platform provided by the customer according to the indications of the Filippetti Group on the basis of sizing and the complexity of the specific uses cases to be guaranteed. The HW configuration depends on the complexity of the solution to be managed estimated on the basis of the growing smartness processing paradigm: Physical, Virtual and Functional. Usually the number of physical sources multiplied by the factor 3 is considered.

The C2VA service component includes:

  • creation of a single tenant on virtualised architecture consisting of 5 Virtual Machines with the following features (Minimum Configuration)
  • ingest infrastructure with a performance of 1,000,000 messages per day with Near Real Time performance;(dependent on local LAN network performance)
  • access to the platform through the standard user interface and use of the widgets available, the system provides concurrent access to up to 20 concurrent users. The scalability of the system is managed on a project based on specific needs to be evaluated in an appropriate sizing session.
  • availability of integration APIs limited to Minimum access services to historical and real time data provided through SDK, in http Rest format for the use of IoT SmartPlatform data and messages in other local identity provider and ESB applications and designed for secure user authentication of the system excluding delegation to external systems.
  • Local system of configuration and monitoring of the implemented use case including the availability of data sent to a specific instance of relational database for reporting;
  • Provision of the specific solution realised as an appropriate tailoring of one or more available solutions. Evolutive and corrective maintenance of the Software platform through the appropriate lan2Lan VPN maintenance channel (Required condition for service delivery)

The economic value of the C2VA fee can be calculated from the list below with the same sizing logics of the C2 fee.

12.2 Sizing Platform solution

C1. Annual fee for IaaS Management (Connectivity Infrastructure)

It depends on the number of physical data sources to be managed, on the number of years of data retention.

Paas Infrastructure Fee (first 50 nodes)

  • Include startup in cloud
  • 2nd level service desk fee on 8 H instance remotely for testing side by side

Paas Infrastructure fee extension based on bands of virtual sensor graph nodes, functional, monitor, widget

  • packages of 50 additional nodes up to 200 nodes graph packets of 100 additional nodes up to 500 nodes infinite graph
  • Additional fees for pre-configured solution (Bundle)

C3. Service Desk Fees

Service Desk

  • Silver 5×7 8h
  • Gold 5×7 12h
  • Platinum 24×7

Canoni aggiuntivi per soluzione pre-configurata (Bundle)

C3. Canone Service Desk
Service Desk

Silver 5x7 8h
Gold 5x7 12h
Platinum 24×7

13. USER INTERFACE

This section aims to provide a clear, useful and solid guide for users of the IoT Smart Platform to use and appreciate this tool in depth with a correct, powerful and functional approach.

The steps for a good use of the platform and the relative functionalities allowing this are indicated and described.

13.1 Access to the System

The system can be reached via a web browser at a public address IoT Smart Platform

By clicking on Start Smart Platform you access the login page in which to enter as the user name username @ username and password the respective password.

Functions are provided upon activation of the service by the Gruppo Filippetti Service Desk to the references provided at the time of subscription.

Figure 1 – Home page

The standard service interface opens and the functional components are briefly described below

13.2 Standard User Interface

  • In the main view, starting from the top, there are a series of icons useful for using the platform: The “Like” icon indicates the availability status of the service and the connection level with the backoffice application. A red “thumbs down” icon means that there are problems with receiving / sending messages with real-time services.
  • An Exit button;
  • The “flag” icon allows you to change the language of the user interface, and the languages currently available are: Italian, English and Serbian;
  • (It is easily possible to localise the application in different languages upon specific customer request). An icon in the form of a “bell” that has the purpose of notifying “alert” and “event” messages generated by the platform following the information collected; the colour that the “bell” icon can assume indicates the nature of the incoming message: “red” for “Alarm” and “yellow” for “Event”;
  • The “+” button icon allows access to the “Smart-Tools” configuration tools to manage the network and its events;
  • The “list” button allows you to open the column used for incoming messages of “alert” and “event”.

Figure 1 – “Alert” and “event” display

On the left side of the main screen you can see a menu that collects the 2 points of view with which you can navigate the configuration of the monitoring platform: the first is visible by selecting the “functional” menu that groups the monitored objects by engineering areas and solutions configured, while the second menu “objects” allows you to navigate the monitored objects through the menu that represents their classification based on the type.

Selecting a solution or an object, in the lower part of the left column, will show you the possible detail options based on the selection.

Figure 3 – Menù

Instead, by double-clicking on the desired option, the map automatically switches to where is installed.

the entity, highlighting each entity with its own icon based on its type.

Figure 4 – Display of entities in the map

By selecting one or more items on the left side of the column, you can access the widgets that control the status and their activity by selecting the “information” button at the top of the map.

Figure 5 – “Information” screen

The detailed view can be accessed by clicking on the “Information” currently displayed as “Information”.

From the “Information” screen, it is possible, through the “Data analysis” button at the top right of the screen, to activate a deeper view of data collection that allows a better view of the selected entity and its data.

Figure 6 – “Data Analysis” screen

14. AVAILABLE WIDGETS

Below is a list of available Widgets.

14.1 Widgets for the Access Control solution

14.1.1 Access Monitoring

14.1.2 Personnel Management

The “Person” point of view is used to add a new user within the platform by entering his name and e-mail address list.

Figure 3 – Person screen

14.1.3 Readers

The “Reader” point of view allows both to add a new RFID reader through the “Label” and the unique “URI” identification field or select one already registered. Once an RFID is read by the reader, its number will be shown automatically in the screen and from here it is possible to add it to the platform.

Figure 4 – Reader screen

14.1.4 Holder

The “Holder/Owner” view allows to assign an already memorised person to an already registered RFID or simply to read the content. In the second case, the RFID number to be assigned will appear automatically on the screen.

Once you have selected the person and RFID, you can add and make effective the connection between the two entities within the platform.

Figure 5 –  Owner screen

14.1.5 Authorisation

The “authorisation” page allows you to associate a registered RFID access point with a person.

To do this, it is only necessary to select the desired access point (automatically obtained from those that are configured within the Smart platform); clicking on it, this will show you the list of all RFIDs registered with the associated user and you will be able to see which one to make accessible through the desired access point.

Once the RFID badges to be associated with the access point have been selected, the configuration and related access limitation is made effective to the Smart platform by selecting the “Update” button located next to the Access Point combo-box selection.

IoT SmartPlatform also provides widgets that allow better management of the same and better control of information in the circuit inside it.

14.2 Automation

The “Automation” widget allows you to send a command to a single and precise physical entity.

Figure 6 – Automation Widget

14.3 Energy Monitoring

14.3.1 Electrical Monitoring

The “Electricity Monitoring” widget allows you to check the information on the consumption of electricity. The monitors that are shown concern real-time consumption, daily consumption, weekly and monthly consumption with related charts. By activating the data analysis it is possible to specifically see the desired energy consumption (daily, weekly, etc.) with the detail of the consumption detected by the various physical sensors.

Figure 7 – Electricity Monitoring Widget

Figure 8 – Electricity Monitoring Widget (detail)

14.4 Environmental Monitoring

The “Environmental Monitoring” widget allows you to check all the information collected by the sensors that are present in the same (presence, temperature, power consumption, etc. …).

Figure 9 – Environmental Monitoring Widget

14.5 Parking Monitoring

The “Parking Monitoring” widget allows you to check the status of the parking bays. Stalls may be free, occupied by authorised personnel with “badges” or occupied by unauthorised personnel.

The “entry time” in the stall is recorded and it is also possible to have a history of the parking status by selecting the desired day via the calendar.

Figure 10 – Parking Monitoring Widget

14.6 Access Control

The “Access Control” widget allows you to control accesses, by means of badges, carried out by the personnel provided with the same. They show the information of the incoming users, the access through which they access, the access time and the eventual success or absence of the access authorisation.

Figure 11 – Access Control Widget

14.7 Helmets Monitoring

The “Monitoring Helmets” widget allows you to check the status of the various helmets in the environment. The status of a helmet can be “Hanging”, “Worn”, “Not worn / Leaning” and “Not present”.

14.8 Mask Monitoring

The “Monitoring Mask” widget allows you to check the status of the various masks in the environment. The status of a mask can be “Hanging”, “Worn”, “Not worn / Leaning” and “Not present”.

14.9 Strain Gauge Monitoring

The “Strain Gauge Monitoring” widget allows you to view information on strain gauges with daily, weekly and monthly reports.

Moreover, for each strain gauge, the widget allows to set the “zero” of the strain gauge and its maximum and minimum alarm threshold.

Figure 12 – Strain Gauge Widget Monitoring

14.10 Inclinometer Monitoring

The “Inclinometer Monitoring” widget allows you to view information on Inclinometers with daily, weekly and monthly reports. Moreover, for each Inclinometer, the widget allows to set the “zero” of the Inclinometer and its maximum and minimum alarm threshold.

Figure 13 – Inclinometer Widget Monitoring

14.11 Widgets for SmartLight solution

14.11.1 Lighting Control

The “Lighting Control” widget allows you to manage the lighting of the lights by following and interweaving different criteria.

The lights, using the widget, can be turned on via a scheduler (day and time), based on the detection of a presence and according to the ambient brightness.

The widget in the scheduler for turning on the lights can assume three values:

On: the lights are on;

Automatic: the lights come on according to the set time, the ambient brightness and according to the presence detection;

Off: the lights remain off.

The widget scheduler also allows you to set the intensity of the lighting when the light is on.

It is possible to set a different control for the day and night time: in the daytime the ambient light level is taken into account (if the brightness falls below a threshold, which can also be configured, the lights are switched on); in the night time only the presence is taken into account.

Finally, it is also possible to set the duration of the maintenance of the “presence status”, i.e. how long the presence state must last, from the last moment in which it is actually detected, so that the lights stay on.

Figure 14 – Lighting Control

14.12 Widgets for Workflow Monitoring Solution

14.12.1 Alarm Management System Widgets (Shifts)

The “Alarm Monitoring” widget is used to set the times in which a given alarm must be signalled, also allowing to set the duration of the alarm.

Figure 15 – Alarm Monitoring Widget

14.12.2 SaveMENOW PPE Monitoring

The Widget indicates the total time spent on each production line for each PPE SaveMENOW.

Figure 16 – SaveMENOW PPE Monitoring

14.12.3 PPE SaveMENOW Battery Monitoring 

The “PPE SaveMENOW Battery Monitoring” widget allows you to check the battery level for each PPE.

Figura 17 – PPE SaveMENOW Battery Monitoring Widget

14.12.4 Line Presence Monitoring

The “Line Presence Monitoring” widget allows you to monitor the number of the PPE SaveMENOW present in real time in the processing line.

Figure 18 – Line Presence Monitoring

14.12.5 Line Presence Monitoring Widget

The “Line Presence Monitoring” widget allows you to view the number of badges present in each production line.

Figure 19 – Line Presence Monitoring Widget

14.13 StreetLight Solution

14.13.1 Monitoring of the Streetlights group

The “Streetlights Monitoring” widget allows groups of street lamps to be formed.

Figure 20 – Streetlights Group Monitoring Widget

14.13.2 Lamps Status Monitoring

The “Lamps Status Monitoring” widget allows you to check the status of the street lamps.

Figure 21 – Lamps Status Monitoring Widget

14.13.3 Monitoring Lamps Exceptions

The “Exceptions Monitoring” widget allows you to define exceptions in the normal routine of switching on and off the street lamps using the concept of hourly and daily scheduling.

Figure 22 – Lamps Exceptions  Monitoring Widget

14.14 Events widget

14.14.1 Widget Description

The widget allows complete monitoring of both real time and historical platform events for the following types:

  • Alarms on measurements of an out-of-range sensor
  • Networking alarms on Platform notification events device communication

Figura 23 – Widget Events

14.14.2 Real Time Events Report

The section of the last events widget shows the list of the last alarm / network / notification events coming from the platform through the IoT MQTT bus and sorted by generation time. Each event is characterised by

  • Source: the type of sensor that caused the event Type: type of event (alarm, networking, notification) Date of the message
  • Generated message of the platform
  • Status: according to the type of the event it can assume the following values:
  • Resolved: the system has sent an alarm return message
  • Fixed the YYYY-MM HH: mm: ss: the message is an alarm whose resolution time has been recovered
  • Checking: the system is checking if the alarm has been resolved
  • Unresolved: the alarm has not yet been solved

WARNING: The resolution matching of an alarm is only available in the historical events section

Figure 24 – “Last events” widget

If there are no active alarms, the system shows a regularity message at the top right. In the event of alarms in progress on measurement / networking, the widget shows an active number grouped by type:

Figure 25 – Active alarms

14.14.3 Historical Events Report

The section of the historical events widget shows the list of alarm / network / notification events recorded during a specific day and stored on Big Data.On the right side of the widget you can select the desired day while at the top you can download the list of alarms in CSV (Comma Separated Values) format.

Figure 26 –  “Historical Events” Widget

14.15 Widgets for the Odour Monitoring Solution

14.15.1 Simulation Choice Cromos Scenario

The “Simulation Choice Cromos Scenario” widget allows to set different simulated values in order to create and test new configuration scenarios.

Figure 27 – Cromos Scenario – Choice simulation

14.15.2 Scenario Cromos

This widget allows to set different simulated values in order to create and test new configuration scenarios.

Figure 28 – Widget Scenario Cromos

The upper right corner indicates if the “real time” data display is active and is shown. It is possible through the calendar to access the history of the displays with daily and hourly granularity. It is also possible to access future predictions (for a maximum of five days) based on the history of the data collected. It is possible to view current wind strength and direction and the detections of the individual sensors located in the area.

15. SMART-PROVISIONING

The Smart provisioning is a tool that allows, in a certain way, a 360 ° control of how to access the platform. It can be accessed via the main interface via the “provisioning” menu.

Figure 29 – Smart Provisioning

15.1 Main Interface

Figura 30 – Smart Provisioning

The main page of the Smart Provisioning, as shown, allows us to have access to many features of the platform, such as:

  • Statistics: allows to view the flow of messages for the tenant; Roles: allows the management of access roles to the platform; ACL: allows the management of access policies to the platform;
  • Users: allows the management of users who can access the platform;
  • Catalogue: makes it possible to customise the value thresholds for the measurements associated with the sensors / objects;
  • Smart IoT SmartPlatform: access to the actual platform; MarketPlace: allows access to the management of the marketplace; Deployer: access the deployer.

Accessing the Smart Provisioning screen with different roles (admin, user etc.) will open different screens. For example entering with the “user” role we will have the following screen:

Figure 31 –  “User” Screen

15.2 Statistics

Figure 32 – Statistics

The statistics screen allows you to view the flow of messages circulating on the platform both in real time (messages / minute) at the top left, and with daily vision, at the top right, with the possibility of comparing the current day with the previous one. In the central part we find the daily comparison, on a weekly basis, of the messages passing through the platform, while on the bottom we find the daily comparison on a monthly basis.

15.3 Roles

Figure 33 – Roles definition

The role management site allows the creation and deletion of roles that will then be assigned to the users of the platform. Each role will be identified by the mnemonic name of the same and the type of the role. If no roles are defined for the tenant in question, it will be possible to automatically add a set of 10 standard roles through a button placed immediately below the standard buttons called “create standard roles”.

Figure 34 – Creating standard roles

It is also possible to add a single role by defining the mnemonic name of the role and the identifying type of the new role in addition.

Figure 35 – Creating new roles

In case you want to delete an already declared role just click on the “delete” button placed next to the role and then confirm it with the request for definitive cancellation.

Figure 36 – User deletion

15.4 ACL

Figure 37 – ACL

It is possible to define access policies both for functional components (e.g. safety, security, facility management, energy) and for basic objects that are part of the smart platform (e.g. areas / zones, equipment, people.).

By sector of the platform it is also possible to manage access to the same for the various roles of users. For each sector, the following permissions can be defined:

  • R: read – the user sees the link;
  • W: write – the widget (if supported) allows the user to modify the content (e.g. change configuration of a device, change platform behaviour in different business cases, etc.); X: execution: the user is enabled to view the contents of the widget (e.g. click on the menu node).<br><br>

The association states are:

  • green: grant; red: deny;
  • neutral: not determined.

The system applies the following logic:

  • if the node has no ACL set the default is allow;
  • a role with a deny takes precedence.

Selecting a component on which ACLs can be applied (e.g. security, facility management, etc.) will open the list of child nodes on which to set the access policies.

Figure 38 –  ACL Setting

For each role it is possible to assign a permission by clicking on the R, W, X buttons; if the ACL for the role in question is defined and allows the indicated action, the button will be green; the button will be red if the ACL is defined but does not allow the indicated action; it will be grey if the behaviour is not defined and therefore the default behaviour will prevail.
The “Apply” button placed next to the node name will allow the same ACL to be applied also for the children of the node under analysis.
By clicking on the “+” icon, you will have access to the children of the node in such a way that you can set specific ACLs for them.

Figure 39 – setting of ACL child nodes

When you modify an ACL for a given role with regard to a node in the menu, a confirmation screen will be displayed asking you whether or not to apply the change you just selected.

Figure 40 – ACL application confirmation

Of course if a user is / has assigned a certain role and the role in question has permissions on a particular node, these permissions are inherited by the user himself.
The roles of default_open allow, for a given role and / or user assigned to that role, to see some open default nodes when accessing the platform.
The roles of this type all start with the prefix “default_open_”.

Figure 41 – Default open

Setting the various ACL permissions to the default open roles, as in the figure below, will allow the node in question to be displayed and marked as default in the platform.

Figure 42 – ACL default_open

On the platform, nodes set up with ACLs to the default_open roles are marked with the “bookmarks” symbol and are automatically opened when the user logs in.

Figure 43 – Default open bookmarks

15.5 Users

Figure 44 – List and user management

The user management page allows us to manage users who can access the platform.
For each user it is possible to set and / or modify the role, edit the information or delete the user.
In case of creation of a user creation, it is necessary to specify the name, the username, the password and the email associated to the same.

Figure 45 – Addition of user

For each user it is possible to modify the information related to it by going to edit mode; it will be possible to change the name and surname of the user and update the password associated with it; the mail is not editable once set.
Finally, still in the edit phase, it is possible to define the home page within the user’s platform when the user logs in.

Figure 46 – Change user

For each user it is possible to assign the same one or more roles by clicking on the “roles” button placed next to the respective entry. A column containing all the roles defined for the tenant that can be assigned to the various users will be opened. For each role you can assign the same to the selected user by clicking on the green “add” button, while to decouple a role from the user just click on the red button of “delete” next to the role previously assigned to the user.

Figure 47 – Role assignment

Finally, it is possible to cancel a user by selecting the “delete” button and then confirming the request for a definitive cancellation.

15.5-Utenti-5-Platform-userguide

Figure 48 – User deletion

15.6 Catalogue

By clicking on the Catalogue button you will be taken to the catalogue management section. The platform is “supplied” with a catalogue containing all the elements present inside it. These elements are divided by category and type and within each type all items present in the platform for the tenant are resorted to in a timely manner.

Figure 49 – Tenant Catalogue

For each category it is possible to see the list of the types pertaining to the same and for each type it is possible to have the list of the instances present within the platform belonging to it.
Each type has, within the catalogue, a series of assigned measures. Within each tenant these measures can be customised in order to allow greater customisation of the product.
For each type it is possible, within the tenant, to add, delete an associated measure and change any relevant values for each measure.

Figure 50 – Type customisation

If the type in question has already assigned some measures by default with the relevant values that concern them (thresholds and relevant values) these are shown.
For each measure already assigned, we can update the limit values of the same (upper and lower threshold) and relevant values; the corresponding text boxes and the updated value will be edited by clicking on the blue update button. Each measure can also be decoupled from the type under analysis.
We can also assign a new measure to the type by selecting from the ones available in the drop-down menu at the top left and setting the relevant thresholds and values for the new measure.

The same applies to the instances of objects of a typology; also for every single instance we can set different relevant values for the associated measures. Unlike the management of measures for types, here we cannot add new measures; the only measures that can be managed in addition are those associated with the type to which the instance belongs. However, for each instance, the relevant values of the measurements assigned to the object can be overridden.
Moreover, from the instance management page it is possible to assign to the node the proactive monitors, which are responsible, after configuration in the appropriate menu, to send alarms if the object in question detects values for a measurement outside the thresholds set or corresponding to one of the values considered relevant.

Figure 51 – Instance management

16. MAINTENANCE TOOL

The IoT Smart Platform system makes a complete maintenance and configuration system available for your installation and configured solutions.

16.1 SmartTool

The Tool can be reached from the main page by clicking on the “+” button in the upper right-hand menu.

16.1.1 Configuration and debugging

The Tool can be reached from the main page by clicking on the “+” button in the upper right-hand menu.

16.1.2 Control of sources and flows

It is the part of the tool that allows you to follow the flow of processing that occur in the backoffice engine to check the correct configuration of the identified usage case.
Please refer to the specific user manual of the Smart Tool for detailed functions.

16.2 SmartMonitor

The Monitor can be reached from the SmartTool page from the top left menu with the “gear” button.

The tool allows you to administer monitoring systems and configure mail lists or lists of numbers to send SMS messages.

Figure 52 – Monitor List

Before a mailing list or sms list can be connected to a monitor in order to receive any alarm signals, it is necessary to define the list and the list members.
To access the configuration of the list it is necessary to select the appropriate keys at the top.

16.2.1 Liste Sms

Figure 53 – Configuration of the sms list

Regarding the sms lists, it is possible to add new lists, delete them and manage the members of the same.
When configuring a list you can choose between the people already present and entered in the system and set their telephone number. Furthermore, for each telephone number on the list, it is possible to “enable” or not the person on the list.

16.2.2 Mailing List

Figure 54 – Mailing list configuration

As for the sms lists, even for the mailing lists it is possible to create new ones and delete the existing ones. It is also possible to configure the contacts that must be part of it, enable them, delete them from the list and set their e-mail address.

16.2.3 Configuration Monitor – SMS Lists

Figure 55 – Monitor – SMS List

Once the sms list has been configured, it is possible to attach it to a particular monitor by selecting the “sms list” button next to the same monitor.
Once the button is pressed on the right side of the screen, the listing of sms lists already attached to the monitor will appear.
It will be possible to attach an already created list to the monitor, delete the list from the monitor, disable it and for each list, configure the sms text that will be sent both in the event of an alarm and in the event of an alarm stopping.

16.2.4 Configurazione Monitor – Mailing List

Figure 56 – Monitor – Mailing List

Once the mailing list has been configured, it is possible to attach it to a particular monitor by selecting the “Mailing List” button next to the same monitor.
Once the button is pressed on the right side of the screen, the listing of mailing lists already attached to the monitor will appear.
It will be possible to attach an already created list to the monitor, delete the list from the monitor, disable it and for each list, configure the text and the subject of the mail that will be sent both in the event of an alarm and in the event of an alarm stopping.

17. IoT SMART PLATFORM USER INTERFACE

17.1 Bookmarks e widgets di ruolo

Reporting what they are with screenshots:

  • Bookmark: on each menu item, the user sees a star that allows it to be set as default. At the bookmark: on each menu item the user sees a star that allows it to be set as default. At the next login, the widget will be automatically opened;
  • Role widgets: they have a different icon and are the ones that are automatically opened for those nodes where the user has a role of type default_open_XXX.

17.2 Preferences

If you enter as admin on demo.it, see the gear button in the top right.  Open it and report the different items with screenshots.

18. OPERATING MODES

Through the use of a consolidated methodology, the implementation of tools and the experience gained over the years, the services of Filippetti S.p.A. ensure success in the implementation of technologies such as: Citrix, VMware and Virtual Application.

The methodology of Filippetti S.p.A.

The difference between making good solutions and building and replicating success stories is given by the methodology.  All our projects are addressed with a project management methodology that allows us to control in every phase the adherence of the solution developed with the needs of our customers and with the agreed objectives.
Thanks to the use of a consolidated methodology over the years, and the ability to develop add-on solutions tailored to the customer, Filippetti S.p.A. helps organisations achieve success in implementing technologies.  The project approach is based on international standards and provides direct responsibility during all the project phases, organised into Analysis, Design, Building/Testing and Rollout.

The Analysis phase

The objective of the Analysis phase is the determination of the objectives for the success of the project, the determination of the technologies and the analysis of the pre-existing environment in which they will have to be implemented, as well as the analysis of the implementation risks.

The Analysis phase is divided into three parts, each accompanied by a deliverable document:

  • Project definition (Project overview)
  • The Infrastructure assessment (analysis of the current infrastructure),
  • Proof of Concept (technology validation environment),
  • Definition of the environment and the objectives
  • Implementation of technologies
  • Testing, scalability and validation of technologies   The Analysis phase can also include the determination of ROI (Return on Investment) through TCO (Total Cost of Ownership) methodologies.

The Design phase

The aim of the Design phase is to realise the architectural design with the technologies defined during the Analysis phase, starting from the infrastructure assessment.
The deliverable of the Design phase is organised into separate sections that will then be reused during the Implementation and Testing phase. The architectural elements can vary from project to project depending on the technologies involved.
The implementation methods and operating processes are also defined in the Design phase.

Build & Test

The Building and Testing phase consists of implementing the solution based on the Design phase and with the objective of running a pilot of the entire environment.

Rollout

The Rollout phase initially has the pilot and the consequent analysis of the results, in order then to move onto the realisation of the entire production environment, and its integration with the management, security and customer support environments.

18.1 Roles and Responsibilities

Azione Team Responsabilità
Analysis and Design Customer / Filippetti Filippetti
Implementation Filippetti Filippetti
Test pre-production Customer / Filippetti Customer
Go-live Customer / Filippetti Customer
Project Managment Customer / Filippetti Filippetti

19. FLEXIBLE DEVELOPMENT METHODOLOGY

The Business Unit Factory of Filippetti S.p.A. has long adopted a flexible development methodology called Scrum.
Scrum is a framework to support the development of complex solutions. It is a flexible development method with features of iterative and incremental models to manage the development of software products. With this, we define “strategy of holistic product development, flexible, where the development teams work as a cohesive unit to achieve a common goal”; the methodology challenges the “traditional” sequential approaches for product development. This model defines the various roles involved in flexible projects (especially those with limited flexible experience) with a complete checklist for monitoring the overall development process so as to ensure the completion of all tasks from planning to development. Since each step in the process is concurrent and active, each is assigned a state of completion and comments that clarify its meaning. The development phases include checklists and temporal relationships as shown in the following diagram:

As shown in the previous figure, the Scrum methodology defines four fundamental points of the Sprint for the inspection and adaptation of the general development process:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

In these phases, a series of well-defined figures contribute to the implementation, monitoring and certification of the completion of the tasks, the phases and the achievement of the objectives. In particular, these figures are classified in: Development Team (The Development Team consists of professionals who work to produce an upgrade in the final solution), Product Owner (maximises the value of the product and the work done by the Development Team), a Scrum Master (is responsible for ensuring the understanding of the Scrum objectives by the Scrum Team).

Phase: Project Initiation. The Product Owner is responsible for ensuring that the tasks are completed (before the start of the sprint)

Phase: Sprint planning. The Scrum Master is responsible for ensuring that the tasks have been completed. (Before the start of the sprint)

Phase: Daily Scrums. The Scrum Master is responsible for the operational aspects; all members of the teams must be present (15 minutes per day)

Phase: Sprint Retrospective. The Scrum Master is responsible for ensuring that all tasks are completed (the whole team participates at the end of each sprint)

Phase: Demo. The Product Owner is responsible for ensuring that all tasks are completed (at the end of each sprint)

Phase: Product and Sprint Release. The Product Owner is responsible for ensuring that all tasks are completed (at the end of each sprint)

20. PROFESSIONAL FIGURES AND SUPPLY OF CONSULTING SERVICES

Filippetti Consulting Service employs an internal organisation composed of professional figures with a high technical profile that is able to meet customer needs through defining application solutions based on the most modern technologies currently available. These professional figures are classified according to the level of experience and professionalism acquired as follows:

Master Project Manager (MPM)

The Master Project Manager of the Filippetti Consulting Service is responsible for managing the team and delivering the solution.

The Project Manager will have the responsibility for the correct completion of the project within the limits of cost and time, taking care of managing the technical and quality requirements, the impact of changes to these requirements and their progress.

The specific responsibilities of this role include:

  • Producing and managing the Project Plan
  • Creating and maintaining the project filing structure
  • Collecting and analysing project data for presentation to the Project Board in key decision-making moments
  • Defining and implementing project controls
  • Capturing and examining the problems inherent in the project, and taking the necessary actions, including taking the possible escalation of problems to the Project Board
  • Planning and controlling quality in the context of the identified products
  • If necessary, advocating a Risk Workshop to define and plan risks. Maintaining and managing the Risk Log for the recording of risks
  • Managing those responsible for risks to ensure timely fulfilment of assigned tasks and to update the Risk Log accordingly
  • Reporting on the progress of the project and on the problems to the Project Board

Performing the Configuration Management function over the entire lifecycle of the project.

Master System Engineering (MSE)

The Master is the professional profile of the Filippetti Company who has developed a proven experience in the analysis, design and management of complex IT systems in large organisations and in conducting projects of particular importance. The professional level of the Master integrates the in-depth knowledge of the customer’s structures and processes with architectures and technologies in the application or system areas.
To qualify for this position, a minimum of 10 years experience is required in consultancy roles and managerial competence.  The Master also participates in a structured training plan and has tools and facilities made available to the Filippetti Company’s knowledge system and by the producers of the proposed technological solutions.

Expert System Engineering (ESE)

The Expert is a professional level that refers to consultants with in-depth knowledge of information system architectures, based on both the products to support the infrastructure, especially in Microsoft, and also the applications, systems and/or development areas. The role lies in setting up, coordinating and actively participating in projects of major importance. The continuous presence of the Expert in the projects aims to ensure the correct addresses and design choices and the constant connection with the entire organisation of the Filippetti Company.

Specialist System Engineering (SSE)

The Specialist is the basic level of professionals experienced in technologies and products implemented by the Filippetti Company for the development of application architectures, and for the realisation of IT infrastructures and development.  With full autonomy and within the Project team, the Specialists carry out consultancy interventions in their field of competence, as well as interventions aimed at transferring knowledge.
The Specialists develop their skills through participation in an extensive and rigorous training plan.

Share
Share
Share