Cyber-physical management system of the computer implemented type for the management of services, in particular of an energy, in particular electricity, distribution operator

Abstract

Combined cyber-physical and business management system, of the computer implemented type, for managing services, in particular the services supplied by an energy, in particular electricity, distribution operator, which system comprises a combination of processing devices, comprising one or more processors and memories containing instructions whose execution by said one or more processors provides to make said processors capable of supplying services for managing hardware operating units present in an electricity distribution network, administrative management services and services for managing maintenance and monitoring activities and / or activities for upgrading said electricity distribution network, as well as internal interface services to the operator and / or interface services to the recipients of the electricity supply, and wherein the system comprises a group of software sub-systems that are independent of each other, each dedicated to the execution of at least one or of some specific technical and / or administrative functionalities, each sub-system being created with different technologies and each with its own data layer which only the corresponding sub-system that owns it can access.

Description

[0001] “CYBER-PHYSICAL MANAGEMENT SYSTEM OF THE COMPUTER IMPLEMENTED TYPE FOR THE MANAGEMENT OF SERVICES, IN PARTICULAR OF AN ENERGY, IN PARTICULAR ELECTRICITY, DISTRIBUTION OPERATOR”

[0002] FIELD OF THE INVENTION

[0003] The present invention concerns a system for managing an electricity distribution network of the computer implemented type, which electricity distribution network comprises a so-called smart metering infrastructure, and which infrastructure in turn comprises: field “smart metering” devices, which in turn include: electrical energy meters provided in correspondence with points of supply of the electrical energy to end users, and which points are distributed over a pre-established territory; preferably, so-called concentrators, which are provided in pre-established branch / transformation nodes toward the low voltage lines that connect a pre-established number of meters; the meters and the concentrators being provided with communication units for communicating with each other and the concentrators being provided with a processing unit configured to perform pre- established functions and with a communication unit for communicating with a central management system and wherein the central management system consists of a group of reciprocally independent software systems, each dedicated to the execution of at least one or some specific functionalities, which software are executed by a processing unit comprising at least one processor, preferably a plurality of processors and / or a cloud-type processing unit.

[0004] BACKGROUND OF THE INVENTION

[0005] The context of the invention is that of an Advanced Metering Infrastructure (AMI), that is, an infrastructure consisting of SW systems, communication devices, and field smart metering devices aimed at implementing the processes for the technical and commercial management of the meters by an electricity distribution company.

[0006] The smart metering infrastructure related to the present invention is of the type based on concentrators located in a secondary sub-station. The key elements of this infrastructure are common to all AMI systems, and therefore also to the present invention, and are shown in figure 16.

[0007] Central system, which implements the business and technical processes of the distribution company;

[0008] Concentrators, that is, devices installed in the field on the low voltage side of the secondary sub-station transformers, which are devices equipped with computational capacity and capable of communicating with the meters installed on the power lines fed by the secondary sub-station where they are installed, and capable of communicating with the central system by means of a TCP / IP communication channel on optical fiber or on cellular mobile radio network (e.g. 4G);

[0009] Meters, located at the points of supply of the electrical energy to end customers.

[0010] The macro-families of processes that an advanced metering infrastructure, that is, also a system according to the present invention, has to manage are of different types:

[0011] Measurement operations, that is: acquiring, validating and publishing data relating to energy consumption by end users that have been determined on the basis of measurements made by means of the meters. This data includes, for example, monthly energy totalizers, daily energy totalizers, power peaks, load curves, that is, sampling of the energy consumed by the user every 15 minutes, etc. The data to be acquired relate to energy withdrawn from the network for consumer-type user devices, and fed into the network for producer-type user devices (e.g. user device equipped with photovoltaic panels), and relate to various electrical energy “markers” linked to the sinusoidal alternating regime of the electrical energy supplies: such as for example the data relating to active withdrawn, inductive reactive withdrawn, capacitive reactive withdrawn, active fed, inductive reactive fed, capacitive reactive fed energy / power.

[0012] Connections, that is, activities related to the commercial management of user devices: new connections, disconnections due to arrears, takeovers, transfers, supply terminations, etc.;

[0013] Technical processes of the distributor, e.g. fault management, checks on possible fraud in progress at the supply, etc.;

[0014] Field device management processes, e.g. installation of the concentrators, “enrolment” of meters (that is, association of the meters with the concentrator), concentrators and meters firmware updates, reprogramming of non-commercial parameters of the meters, etc.;

[0015] Mass replacement campaign, which occurs when the distribution company has to replace the entire installed fleet, by switching from traditional electromechanical meters to smart meters, that is, meters that are provided with a hardware / software configuration that gives them computational capacity to execute instructions relating to the performance of specific functionalities, or by switching from a previous generation of smart metering devices to the next.

[0016] All these processes are united by the fact that they are “guided” by the central system, but always have as target a device in the field, be it a concentrator or a meter.

[0017] For each of these families of processes, the execution of the activity can take place through “remote management”, that is, entirely remotely, or “in the field”, that is, by sending an operational team to the device. Some processes have to necessarily be carried out in the field, such as installation or replacement activities due to failure.

[0018] In general, it is in the distributor’s interest to maximize the number of activities that can be performed remotely without sending personnel in the field, since the execution times and operating costs of an activity performed remotely are orders of magnitude lower than the costs of an activity performed in the field.

[0019] In this context, a problem which the present invention is based on is related to the fact that an adaptation of the infrastructures of the distribution network, and in particular of the devices described above relating to the development of smart metering technologies, necessarily also requires a development of the processes and systems for managing such devices in order to achieve the aforementioned maximization of the activities carried out remotely and / or automatically.

[0020] Another problem, which is in any case an expression of the more general problem outlined above, is linked to the new requirements and KPIs set by the Italian “Autorita di Regolazione per Energia Reti e Ambiente” (ARERA - Regulatory Authority for Energy, Networks and Environment) for second generation smart metering systems.

[0021] Enel Grids was one of the first distributors in the world to build an Advanced Metering Infrastructure, starting in 2001. This infrastructure includes about 32 million smart meters installed at end customers and about 380,000 concentrators installed inside the secondary sub-stations, and it is one of the largest in the world.

[0022] This infrastructure’s central system provided a substantially monolithic architecture in which all the functionalities and all the data were concentrated on a few servers, and in particular most of the management logic and data were concentrated on a large database instance, to increase the performance of which it was necessary to resort to vertical scaling techniques. This type of infrastructure was designed to support the regulatory requirements of the first generation of Advanced Metering Infrastructures.

[0023] As the end of the life span of the first generation of AMIs approaches, the Authority, through the publication of Resolution 87 / 2016, has set requirements and KPIs for second generation Smart Metering systems. Among the various requirements, the most relevant for the conception of the invention are the following:

[0024] 1. Acquisition, validation and daily publication of the load curves for the 6 energy markers by midnight of the day following the day of consumption for 95% of the measurement points; 97% within 4 days of the day of consumption.

[0025] 2. Successful execution of “punctual” operations through remote management (excluding mass operations) no lower than 94% within 4 hours of the request; no lower than 97% within 24 hours of the request.

[0026] 3. Successful execution of “mass” operations through remote management for 94% of meters in service within 30 days; for 98% of meters in service within 60 days.

[0027] 4. Making a secondary sub-station operational within 60 days of installing the first second generation meter at a point powered by the same sub-station. Making all the substations of a same territorial area operational within 120 days of the implementation of the territory’s first sub-station, for territories with a number of measurement points lower than 20,000; within 180 days, for territories with a number of measurement points greater than 20,000 (by ‘making a secondary sub-station operational’ we mean that the requirements and KPIs of Resolution 87 are applied to all second generation meters powered by the sub-station).

[0028] These requirements and KPIs relating to second generation remote management represent a “leap” compared to those of the previous generation of meters, and pose a series of technical problems, including:

[0029] • Operation success rate: since these are remote management operations, the 95% success rate on a daily basis of requirement 1 means that every day 95% of the population of second generation meters has to be successfully “read” remotely. For this to happen consistently every day, two factors have to occur:

[0030] - the meters have to be reachable by the system-concentrator-meter remote management chain, and they have to be enrolled, that is, associated with the respective concentrator; this operation takes place only once, downstream of the installation of the meter;

[0031] - the meters have to be read successfully every day, taking into account that every day a portion of the meters may not be reached by remote management due to transient connectivity problems or disturbances on the communication channel of the central system with the concentrator, or on the communication channel of the concentrator with a meter.

[0032] The requirement in point 3, while allowing for what appears to be plenty of time to perform the mass operations, is equally difficult to comply with due to the very high success rate of 98% that it sets as an objective: such high rates were not achievable with the first generation AMI, since a part of the meters cannot be remotely managed for various reasons, such as mobile radio connectivity problems on the central systemconcentrator channel, disturbances along the concentrator-meter communication channel, network maintenance activities leading to a power outage of the concentrators, failures of the concentrators or meters, etc.

[0033] • Operation execution times: for example, requirement 2 dictates that punctual operations are carried out through remote management on 94% of meters within 4 hours: while executing a single remote management activity on a meter that can be reached remotely can be completed within a few tens of seconds, the complexity lies in the fact that, on the one hand, the distribution company has to perform millions of remote management operations every year, and on the other hand that this objective has to be achieved not on the individual meter but on 94% of the base installed, regardless of any connectivity problems or disturbances.

[0034] • Volumes of data to be acquired and processed: requirement 1, relating to the acquisition of daily load curves, represents a revolution compared to the requirements of the previous generation which provided, for the majority of meters, the acquisition of only the totalizers once a month. Considering that there are, for example, 32 million Enel Grids metering points in Italy, and considering the quantity of data to be acquired based on the different types of supply, the number of data points has gone from 1.4 billion data / month to 300 billion data / month, with an increase of more than 200. In addition, the requirement provides that the data have to be acquired, validated and published by midnight of the following day. • Management of the mass replacement campaign. Complying with the KPIs on the timings to make the system operational requires planning, performing the replacements of the meters in the field and enrolling, that is, associating, the meters with the system in a very short period of time, all with the additional complexity related to the fact that, while many distributors across the world have not yet carried out the first mass replacement campaign to replace electromechanical meters with smart meters, in Enel Grids’ case, for the first time, the campaign that was faced was to replace smart meters with smart meters, with the need to make the normal commercial and technical management activities (contract changes, fault management, etc.), which has the order of magnitude of millions of work orders per year, coexist with the activities of installing meters for the mass replacement, which according to plan provides for peaks of 6 million replacements per year.

[0035] • Data quality. The volumes of the replacement campaign, combined with the normal activities of a large distribution company, result in the creation and change of huge volumes of data. The daily acquisition of load curves alone results in the input of more than 10 billion measurement data points per day, of which multiple versions are created during the various steps of processing the measurements. Even the registry data (supply data, meter data, etc.) are strongly affected during the course of a replacement campaign, both in a punctual manner in the face of the replacement of a meter, and also in a coordinated manner when a sub-station becomes operational. In distributed architectures, such as those of the latest generation AMIs, the same datum is often present in multiple data layers belonging to different systems: it is therefore essential to implement techniques that allow to minimize the risk of data misalignment because, since this is data that supports a service provided to end customers, misaligned data can lead to incorrect billing or even interruptions in the electricity service to an end customer. Ensuring the consistency of data in all the data layers participating in the AMI, minimizing the risks of misalignment, is a fundamental technical issue to be taken into account, since in light of the volumes of changes involved, even very small percentages of misalignments can cause disruptions in service to tens of thousands of customers.

[0036] A second aspect linked to data quality is historicization. The distribution company needs to keep track of the evolution history of the data, both measurement and also registry data; it needs to be able to reconstruct this history for each entity, even years later, for example in order to manage complaints from end users, and it needs to be able to modify this history even starting from a past date where errors in its tracking are identified, errors that are physiological (for example due to human errors of data entry where the acquisition or birth of a datum do not have an automated origin).

[0037] First generation AMI infrastructure is therefore unable to meet the new requirements. It has therefore become necessary to redesign the entire infrastructure from scratch, bringing innovations in all its fundamental components: meters, concentrators, and central system, through various innovative aspects of second generation remote management.

[0038] STATE OF THE ART: TYPES OF AMI ARCHITECTURES

[0039] Traditional central systems for managing an Advanced Metering Infrastructure essentially fall into one of three types:

[0040] • “Monolithic” central systems (fig. 17) consisting of a single business logic component and a single data layer component capable of executing all the processes supported by the AMI.

[0041] • Central systems consisting of separate systems (fig. 18). These separate systems each have their own business logic and dedicated data layers, and can have different architectures, specialized in the role that that system has to perform. Typically, each system realizes one or more archetypes described in the literature, relative to the systems that make up an AMI. Typical archetypes are: o AMI Head End System (HES): a system that manages the execution of operations on the meters in remote mode (remote management): it is responsible for the management of the enrolment of the meters into the AMI in order to make them “remotely manageable”, the management of the remote connection with the field devices, the execution of the measurement acquisition activities and execution of work orders, and the management of mass technical activities, such as the devices’ software update. These systems are typically the system of record of the concentrators’ registry data, in the event the distributor’s AMI provides for this type of devices. o Work Force Management System (WFM): a system that manages the execution of operations on meters in local mode, that is, by means of on-site operating teams. Typically consisting of a server component that manages the planning, assignment and optimization of field activities and the synchronization of activities toward the smartphone of each operative; and a mobile component, running on smartphones supplied to each operative who receives the list of activities to be performed, and provides supporting apps to perform such activity and, if the field devices support it, to communicate with meters and concentrators so as to automate programming and reading activities. o Meter Data Management System (MDMS): a system whose main role is to implement VEE processes, that is, validation, estimation and editing of measurement data. By ‘validation’ we mean a series of processes for which measurement data are verified and cross-referenced to determine correctness; for example, the total energy measured by means of the daily load curve, integrated across the entire month, has to coincide with the energy measured by the monthly totalizers. By ‘estimation’ we mean those processes of estimating and reconstructing measurements that are triggered when the measurements are missing data (for example due to lack of connectivity or failure of a meter): any missing data is estimated on the basis of other validated data available for that meter, or historical data of the same meter, or data of supplies with the same characteristics as those with the missing data. Editing allows an operator to manually edit measurement data. The systems. These systems are typically the system of record of the meters’ registry data.

[0042] AMIs consisting of separate systems allow to maximize the efficiency of each system, since each system potentially has an architecture and a technological stack (e.g. RDBMS and NoSQL) dedicated to and specialized for the processes it has to perform, but they present the problem of managing multiple copies of the same data, since there are data, such as the meter data, which are needed by all AMI systems, and since each system has a separate data layer, there is the problem of how to synchronize the data between the system of record (typically the MDMS system) and the other systems working on the same data. Typically, even if there is only one system of record (SOD) for each entity that constitutes the final source of truth for that entity, with this type of architectures multiple systems modify the same datum on their local data layer, and only subsequently are the data aligned by means of synchronization flows between all the systems involved in the datum, thus creating data consistency risks.

[0043] • Modular type central systems consisting of a common and shared data access layer, also resulting from the composition of heterogeneous storage technologies (e.g. RDBMS and NoSQL) and functional modules that share the same architecture and technologies to implement the different processes of an AMI. These systems solve the problem of data consistency by using a single layer of data layers, without presenting multiple copies of the same datum, but they cannot take advantage of the benefit of having specialized architectures and specialized data layers based on the process to be performed, which in the case of large distribution companies such as Enel Grids in Italy, may not guarantee compliance with the performance dictated by Resolution 87 / 2016.

[0044] The document US 2012 / 0296869 Al describes an energy information exchange system for synchronizing source systems in a utility computing environment with target systems that use data from source systems. Source systems can include advanced measurement infrastructure (AMI) measurement devices, head-ends, portals, etc. Source systems can also include customer information systems, data stores, databases, billing systems, maintenance systems, logistics systems, systems that supply data on measurement devices, and other systems that supply data to other systems in a utility computing environment. A target system can include a billing application that generates invoices that are associated with a customer account for a particular billing period. Consequently, this application can generate an invoice from energy usage data for the billing period as detected by one or more AMI measuring devices. In addition, the billing application can use energy usage information along with data about a rate plan associated with the customer account.

[0045] The document US 2021 / 0234722 Al describes an apparatus able to be connected to a system for the automatic management of electricity meter readings (AMM). The AMM system comprises a data concentrator to which smart electricity meters are connected, by means of a first power line network. Each data concentrator is connected to a management system comprising a management entity by means of a second network and acts as a relay between the aforementioned meters and the management system. The apparatus is connected to a relay concentrator by means of a third network. The apparatus also comprises an interface for communication with a fourth network, which allows a device connected to that fourth network to communicate with the apparatus. The latter is able to receive data from one or more devices connected to the fourth network, to verify that the data received comply with a predetermined criterion that depends on a type of data transmitted, and to transmit an alarm to an administration server included in the management system in the event of non-compliance of such data; and it is able to forward a command sent by the administration server and intended for a device connected to the fourth network.

[0046] According to a first aspect, the present invention is therefore based on the problem of providing a management system of the type described at the beginning, which is able to overcome the disadvantages of known systems and at the same time allows to achieve the performances required by regulations regarding ordinary and extraordinary management operations of an electricity distribution network.

[0047] The invention also aims to perfect further aspects of the management system that will be defined and described below in the following description, with reference to the description of individual sub-systems that make up the management system.

[0048] BRIEF DESCRIPTION OF THE INVENTION

[0049] GENERAL ARCHITECTURE OF THE SOLUTION ACCORDING TO THE

[0050] PRESENT INVENTION

[0051] The present invention is set forth and characterized in the independent claims. The dependent claims describe other characteristics of the present invention or variants to the main inventive idea.

[0052] Compared to traditional types of AMI architectures, the management system according to the present invention adopts a different architecture, dictated by the need to address all the technical problems posed by the Italian regulatory requirements for second generation smart metering systems, in the case of large distribution companies with a number of customers in the tens of millions.

[0053] Mainly, the invention therefore solves the aforementioned problems with a system for managing an electricity distribution network of the computer implemented type, which electricity distribution network comprises a so-called smart metering infrastructure, and which infrastructure in turn comprises: field smart metering devices, which in turn include: electrical energy meters provided in correspondence with points of supply of the electrical energy to end users and which points are distributed over a pre-established territory; preferably, so-called concentrators, which are provided in pre-established branch / transformation nodes toward the low voltage lines that connect a pre-established number of meters; the meters and the concentrators being provided with communication units to communicate with each other and the concentrators being provided with a processing unit configured to perform pre- established functions and with a communication unit for communicating with a central management system and wherein the central management system consists of a group of specialized software systems that are independent of each other, and each is dedicated to the execution of at least one or some specific functionalities, which software are executed by a processing unit comprising at least one processor, preferably a plurality of processors and / or a cloudtype processing unit, and which management system is further characterized by the fact that each sub-system is created with different technologies and each is provided with its own data layer which only the corresponding sub-system that owns it can access, and which data layer is optimized on the basis of the functions of the sub-system consisting of specific and unique data of the corresponding sub-system and of data common to one or more of the additional sub-systems; the common data present in the data layer of each sub-system consisting of copies of the corresponding data present in the private data layer of a master data management subsystem; in the data layer of each sub-system there being stored only the copies of the data common to one or more other sub-systems that are functional to the execution of the functions of the sub-system; the master data management sub-system being configured to perform a common service for the one or more sub-systems, and comprising its own private data layer and being configured to perform functions of storing the common data; exclusive functions of modifying the common data; functions of synchronizing the modifications of the common data with the corresponding copies present in the one or more sub-systems.

[0054] According to one embodiment, the common data comprise technical registry data defining the type of supply, technical registry data defining the meter and / or the concentrator with which the meter is associated, geographical positioning data of the meters, data defining the functional state of the concentrators and / or the meters, data measuring and / or indicating the time data relating to the measurements, data relating to the determination of physical characteristics of the supply calculated on the basis of the measurement data, statistical data relating to the supply and predictive data relating to the supply of electrical energy with reference to one or more meters and / or concentrators. However, this list should not be considered exhaustive, but only exemplary since it is possible to provide additional types of data.

[0055] In particular, the proposed architecture consists of:

[0056] A group of sub-systems for managing activities and / or technical devices that are independent of each other, each with a specific architecture, technology stack and data layer (e.g. RDBMS, Key-Value Store, Document DB, etc.) and optimized according to the role that the sub-system has to fulfill. These systems have different roles: Head End Systems (HES), Work Force Management Systems (WFM), Meter Data Management Systems (MDMS), Business Intelligence / Data Analytics systems that collect data from all the systems in the suite, and others that will be described in the following description.

[0057] According to a further characteristic, in combination with the aforementioned subsystems, it is possible that the central system also further comprises a group of subsystems that make available services common to the aforementioned sub-systems dedicated to technological activities described above, and in which group at least one or more of the following sub-systems are included: the sub-system that provides a common portal service and that unifies the user experience of all the sub-systems of the central management system; the sub-system that brings together the AAA (authentication, authorization, accounting) functionalities; a system with a specific role to centrally manage all commercial and technical operations within the AMI, including those related to the Mass Replacement Campaign. In the terminology used by distribution companies, these operations are called “works”, and can be carried out through remote management (as often as possible), or in the field. A system with this role is not described in the literature within AMI solutions.

[0058] A Master Data Management sub-system that represents the system of record of all data common to two or more systems in the suite, which represents the central point of the suite’s data architecture.

[0059] In particular, the data architecture of the Beat suite is characterized as follows: Each sub-system of the Beat suite has a private and independent data layer. This data layer consists of the union of data specific and unique to that sub-system (for example, data on the measurements validated in the case of the Meter Data Management system), and data common to one or more of the other sub-systems of the suite (for example, data identifying the meter or the supply point). Common data are those for which there is a need to ensure consistency and alignment between all instances of that datum.

[0060] Technical activity management sub-systems directly update data not shared with other systems on their own dedicated data layer.

[0061] There is a master data management sub-system that acts as a system of record for all this common data, and it is the only sub-system where it is allowed to make changes to this data. Whichever sub-system of the suite has to modify the common data, for example, the WFM sub-system has to associate a meter with a supply point in case of new installation, or the HES sub-system has to indicate that a meter has been enrolled, associating it with its concentrator, these data are modified exclusively within the data layer of the master data management sub-system. The sub-system will then synchronize the changes with all the sub-systems that hold a local copy of the datum. Each business sub-system, relative to a common entity (for example the meter), holds the only subset of attributes that are of interest to that specific sub-system, so as to minimize the total number of copies of each attribute, while reducing the risks of misalignment.

[0062] The architecture of the central system is represented according to a diagram comparable with the traditional architectures shown in figures 16 to 19 and is represented in figure 1.

[0063] The architectural approach according to the present invention allows to reconcile the existence of sub-systems with internal architectures and data layers dedicated to and optimized for the specific role of each sub-system, with the benefits of a common and shared system of record for all data used by multiple sub-systems.

[0064] The fact that each system has a specialized architecture has allowed the central system according to the present invention to reach and exceed the KPIs set forth by Resolution 87, solving, within each sub-system and based on the role it plays in the AMI, the specific technical problems of the role itself: for example, an AMI Head End sub-system and a Meter Data Management sub-system, while both having to manage 32 million meters, need to adopt different architectures, technological stacks and types of data layers because their purpose is different: the first has to manage the accumulation and grouping of requests to the concentrators as efficiently as possible, the other has to process billions of data multiple times in a few hours.

[0065] The use of sub-systems that make available common “administrative and / or commercial and / or marketing and / or legal” services, such as portal services and AAA services, allows to offer the user a better user experience by being able to move from one sub-system to another transparently, and without perceiving the existence of different subsystems.

[0066] The conception of a sub-system specifically dedicated to centralizing the management of the execution of work has allowed to reach and exceed the KPIs relating to the execution times of remote management operations, and those relating to the mass replacement campaign, allowing the distribution company to manage the millions of commercial and technical works performed each year for normal business operation, together with the millions of works related to the mass replacement campaign, planning the execution of the campaign, centrally defining rules of priority, dependence, and precedence among all the different types of works typical of an AMI.

[0067] In relation to the above, it is worth noting that in traditional AMI systems there is no centralized work management, and every system capable of generating work, which in a typical example are systems dedicated to managing mass replacement campaigns, traditionally separated from the sub-systems that generate commercial works, “sees” and controls only “its” works, with the consequence that it is not possible, for example, to indicate priorities that allow “re-connection” works to take priority over previously generated “replacement campaign” works.

[0068] The data architecture ensures that the master data management sub-system concentrates all the complexities of managing the system’s critical entities in a single component of the architecture, on the one hand guaranteeing its consistency, on the other implementing a sophisticated historicization logic that does not then need to be replicated in the systems that hold a copy of a subset of the common data: the versioning of the entities, with arbitrary historical depth, is carried out only within the master data management sub-system, while the sub-systems that hold a copy of the data use only the “current” version of the data themselves.

[0069] The central system object of the present invention has further innovative characteristics that specifically solve some of the problems described above, and in particular the technical problems related to second generation remote management. In general, the following is a list of the general characteristics and technical problems that these characteristics solve:

[0070] Architecture with specialized components and master data management: solves all the problems listed above;

[0071] Meter enrollment with a dual technology system:

[0072] Solves problems related to the success rate of remote management operations;

[0073] Problem Manager sub-system: solves the problem relating to the success rate of remote management operations;

[0074] Event architecture and consolidation technique for mass remote management activities: solves the problem of the very high volumes of data to be acquired and processed;

[0075] Centralized sub-system for the management of work orders and the mass replacement campaign: solves the problem related to the execution times of the operations and the management of the mass replacement campaign;

[0076] Data versioning sub-system with bitemporalism technique: solves the problem related to data quality;

[0077] Sub-system for recalculation and automated validation of historical measurements: solves the problem of data quality;

[0078] Multi-environment measurement functionality: solves the problem of data quality;

[0079] Management of the measurement data cold copy: solves the problem of the volumes of data to be acquired and processed and the execution times of the operations.

[0080] The systems or the functionalities as above can be provided either alternately to each other, or in any combination and sub-combination with each other and with the central system according to the present invention, defined by the combination of characteristics of the main claim 1 of the system, and they are the subject of sub-claims or additional claims.

[0081] BRIEF DESCRIPTION OF THE DRAWINGS

[0082] The characteristics generally disclosed above and possible additional characteristics, as well as the advantages resulting therefrom, will become apparent from the following description with reference to some non-limiting example embodiments, shown in the attached drawings wherein:

[0083] Figure 1 is a high-level block diagram of an example embodiment of a management system according to the present invention. Figure 2 is a block diagram of a functional diagram of an example embodiment of a management system according to the present invention.

[0084] Figure 3 is a block diagram of an example embodiment of an HES sub-system for low voltage meters according to the present invention.

[0085] Figure 4 is a block diagram of an example embodiment of a Master Data Management sub-system according to the present invention.

[0086] Figure 5 shows an example embodiment of the functional architecture of an example embodiment of the Meter Data Management sub-system.

[0087] Figure 6 shows a particular example embodiment of the technical architecture of the WMF sub -system.

[0088] Figure 7 shows a particular example embodiment of the technical architecture of the Work Management sub-system.

[0089] Figure 8 shows a detailed example of the AMI Head End sub-system for medium and high voltage meters.

[0090] Figure 9 shows 3 examples of execution flow for different types of work orders, showing the sequence of involvement of the different functional modules.

[0091] Figure 10 shows a diagram representing the data versioning process.

[0092] Figure 11 shows an example of the remote execution process of requests for activities on the meters.

[0093] Figure 12 shows an example of an app suite for mobile applications.

[0094] Figure 13 shows an example configuration of the Problem Manager sub-system.

[0095] Figure 14 shows an example of the flow of operations between Problem Manager and other systems.

[0096] Figure 15 shows two examples embodiments, figure 15a) related to the state of the art and figure 15b) according to the present invention, respectively, of the connection between a concentrator and meters.

[0097] Figure 16 shows a high-level block diagram of an example embodiment of an AMI.

[0098] Figures from 17 to 19 show three variants of management systems according to the state of the art.

[0099] Figure 20 shows tables of an example of how changes are managed.

[0100] Figure 21 shows a diagram of the architecture of a sub-system for generating cold copies of the main database.

[0101] We must clarify that the phraseology and terminology used in the present description, as well as the figures in the attached drawings also in relation as to how described, have the sole function of better illustrating and explaining the present invention, their purpose being to provide a non-limiting example of the invention itself, since the scope of protection is defined by the claims.

[0102] To facilitate comprehension, the same reference numbers have been used, where possible, to identify identical common elements in the drawings. It is understood that elements and characteristics of one embodiment can be conveniently combined or incorporated into other embodiments without further clarifications.

[0103] DETAILED DESCRIPTION OF SOME EXAMPLE EMBODIMENTS

[0104] Figure 16 shows a typical configuration of a so-called Advance Metering Infrastructure (AMI), comprising a central management system indicated with 1600 which consists of a management program executed by one or more operating units, or on units forming part of a so-called cloud provider, as indicated by way of example in the drawing. Forming part of the system, as already described above, are also a field unit consisting of so-called concentrators 1610 that are provided in secondary sub-stations 1620 distributed throughout the territory and that serve the low voltage lines 1640 that reach the energy withdrawal points provided for the different users, and in correspondence with which so- called meters are provided, that is, meters of the energy delivered, which are indicated with 1620.

[0105] The central system communicates with the concentrators 1610. Communication can take place according to different modes, preferably of the wireless type, such as with a cellular network 1650 for example, as shown in figure 16. In the state of the art, communication between the concentrator 1610 and the smart meters 1630 associated with a concentrator takes place using the low voltage lines 1640 for the supply of electrical energy to the withdrawal point in correspondence with which a meter 1630 is provided.

[0106] The infrastructural units shown in figure 16 are common to the electricity distribution networks and are also provided in combination with the management system of the present invention.

[0107] Figures from 17 to 19 show the three configurations of an AMI management system according to the state of the art, as described in the introduction to the present disclosure.

[0108] Figure 17 shows a monolithic central system 1700 consisting of a single business logic component 1720 and a single data layer component 1740 capable of executing all the processes supported by the AMI. The system is shown similarly to figure 16 in combination with a distribution network infrastructure that comprises one or more concentrators 1710, each of which is associated with one or more meters 1730. The benefits and functionalities of this system according to the state of the art are described above.

[0109] Figure 18 shows another architecture that is known in the state of the art.

[0110] In this architectural configuration, the central system consists of separate systems indicated with 1850, 1851, and 1852. These separate systems 1850, 1851, and 1852 each have a business logic 1820, 1821, 1822 and a dedicated data layer 1840, 1841, 1842, and can have different architectures from each other, specialized in the role that that system 1850, 1851, and 1852 has to fulfill. Typically, each system 1850, 1851, and 1852 realizes one or more archetypes described in the literature, relative to the systems that make up an AMI. In particular, the system 1850 is configured to perform Meter Data Management functions, while the system 1821 is configured to perform Work Force Management activities and the system 1822 to perform Head End activities. The drawing shows only a few systems from those that are possible, which can also be provided in greater number and with additional functions to those indicated in the drawing. In figure 18, 1810 and 1830 denote the concentrators and meters present in the network and managed by the system 1800.

[0111] Figure 19 shows a block diagram of an additional configuration of management systems for AMIs that is known in the state of the art. In this case, the central system 1900 is of the modular type and consists of a common and shared data access layer 1940, also resulting from the composition of heterogeneous storage technologies, such as for example RDBMS 1941 and NoSQL 1942, and of functional modules 1950, 1951 and 1952 that share the same architecture and the same technologies to implement the different processes of an AMI. In figure 19, 1910 and 1930 denote the concentrators and meters present in the network and managed by the system 1800.

[0112] Figure 1 shows, with a graphic similar to figures from 16 to 19, the architecture of the central management system according to the present invention. Compared to the types of traditional AMI architectures referred to in figures from 16 to 19, the architecture of the central management system indicated with 50 is different.

[0113] In particular, the architecture shown in figure 1 consists of a group of reciprocally independent sub-systems indicated with 2, 3, 5, 5, 10 which are specialized in their respective functionalities, each with architecture, technology stack and specific data layer (e.g. RDBMS, Key-Value Store, Document DB, etc.) and optimized according to the role that the sub-system has to fulfill. These sub-systems fulfill the role of HES (Head End System) block 10, WFM (Work Force Management) block 4, WOM (Work Order Management) block 5, MDMS (Metering Data Management System) block 3, MDM (Master Data Management) block 2.

[0114] There is also provided a group of sub-systems which make available services common to the aforementioned sub-systems and which are indicated overall with 56. According to one embodiment, these sub-systems can comprise: a sub-system that supplies the portal service that unifies the user experience of all sub-systems; the sub-system that brings together AAA (authentication, authorization, accounting) functionalities; the Business Intelligence / Data Analytics sub-system that collects the data from all the sub-systems provided.

[0115] The sub-system 5 has the specific role of centrally managing all the operations within the AMI, including those related to the Mass Replacement Campaign. The Master Data Management sub-system 2 represents the system of record of all data that are common to two or more sub-systems.

[0116] In particular, the data architecture provides that each sub-system has a private and independent data layer. This data layer consists of the union of data specific and unique to that system 65, 63, 64, 70 (for example, data on the measurements validated in the case of the Meter Data Management system), and data common 75, 73, 74, 76 to one or more of the other systems of the suite (for example, data identifying the meter or the supply point). Common data are those where there is a need to ensure consistency and alignment between all instances of that datum.

[0117] According to one embodiment, the sub-systems directly update data not shared with other systems on their own dedicated data layer. The master data management sub-system acts as a system of record 62 for all this common data, and it is the only sub-system where it is allowed to make changes to this data. Whichever sub-system has to modify the common data (for example, the WFM sub-system 4 has to associate a meter 58 with a supply point in case of new installation, or the HES sub-system 10 has to indicate that a meter 58 has been enrolled, associating it with its concentrator 51), these common data are modified exclusively within the data layer 62 of the master data management subsystem 2. The sub-system will then synchronize the changes with all the sub-systems that hold a local copy of the datum. Each sub-system, relative to a common entity (for example the meter 58), holds the only subset of attributes that are of interest to that specific subsystem, so as to minimize the total number of copies of each attribute, while reducing the risks of misalignment.

[0118] Figure 2 shows a block diagram that represents a logical diagram of an example embodiment of the system according to the present invention.

[0119] The diagram shows the following sub-systems:

[0120] 1 : LV AMI Head End System (HES) sub-system, for the remote management of low voltage residential smart meters with infrastructure based on concentrators.

[0121] 2: Master Data Management sub-system for the management, historicization and synchronization of data entities common to the suite’s multiple sub-systems.

[0122] 3: Meter Data Management System (MDMS) sub-system, which centralizes measurement data processing operations.

[0123] 4: Work Force Management (WFM) sub-system, consisting of a server component 4 and a component consisting of mobile applications running on Smartphones 304.

[0124] 5: Sub-system for managing the distribution company’s work orders, carried out either remotely (through HES) or locally (through WFM - Work Order Management). It also contains the full functionality for managing the Mass Replacement Campaign.

[0125] 7: Concentrator, field device installed at the secondary sub-stations of the electricity distribution network capable of communicating both with the central system and also with a certain number of LV meters associated with it.

[0126] 10: MV / HV AMI Head End System (HES) sub-system, for the remote management of commercial and industrial smart meters, in medium and high voltage, with point-to-point type communication (each meter is equipped with a communication module, e.g. a modem, to communicate directly with the central system).

[0127] 12: Sub-system that provides common SSO, and Authentication, Authorization and Accounting (AAA) services to the other components of the suite.

[0128] 13: Sub-system that provides the common portal and navigation services to the other components of the suite, as well as the UI / UX components necessary to build the user interfaces, ensuring that all sub-systems appear to the user as a single system, with a standardized look & feel.

[0129] 14: Business Intelligence sub-system that gathers the data from all the specific data layers of the individual systems and the common data from the Master Data Management sub-system within a multidimensional data layer, to allow Data Analytics activities on all the data of the suite.

[0130] 15: Sub-system that provides common Real Time Application Monitoring services of the performance and volumes of the suite’s sub-systems.

[0131] 17: Low voltage residential smart meter. In the case of Enel Grids Italia, the meters subject to a mass replacement campaign for second generation smart metering belong to this category.

[0132] Fig. 2 also shows a simplified view of how these sub-systems work together to build the macro-processes of an AMI, which are:

[0133] Remote management processes: this is the family of processes related to the management of field devices, essentially concentrators and meters.

[0134] Measurement processes: this is the family of processes related to the acquisition and processing of measurements from meters in the field.

[0135] Work processes: this is the family of processes related to so-called commercial management (contractual changes, disconnections / reconnections, transfers / takeovers, etc.) and technical management (fault management, reprogramming of meter noncommercial parameters, etc.) of supplies, and to the maintenance of field devices (replacement of faulty devices, etc.).

[0136] Registry data processes: this is the family of processes related to the manual and automated modification of the registry entities shared by multiple systems, their historicization and the synchronization of these entities between the Master Data Management system and other systems in the suite.

[0137] Figure 2 also shows, in the left column, the main external systems that participate, together with the management system, in the end-to-end form of the distributor’s processes.

[0138] Below is a detailed description of the various sub-systems present in figure 2 with regard to the hardware / software characteristics that are functional to solve the technical problems described above.

[0139] AMI HEAD END SUB-SYSTEM - LV METERS

[0140] Number 1 indicates one of the so-called AMI head end sub-systems for the acquisition from devices, such as concentrators 7, connected to the low voltage network.

[0141] The main functionalities as provided in an embodiment are:

[0142] • Remote Meter & Concentrator Management: The sub-system remotely manages the parameters and software of the concentrators 7 and the meters: it acquires their profile data and load curves, and performs a possible recovery & tuning;

[0143] • MCE & Commissioning: the sub-system is able to carry out the installation of concentrators 7 and build the concentrator / meters link both through PL (Power Line) and also RF (Radio Frequency). The link can be multiple and contribute to a strong increase in the reachability and executability performance of remote management activities;

[0144] • T&C Work Order management: in the architecture of this sub-system 1 there is provided a layer of business logic that allows it to easily manage technical and commercial work orders;

[0145] • Problem Manager: The sub-system 1 provides a Ticket Management service through cooperation with a sub-system indicated with 11 in figure 2.

[0146] The architecture of the sub-system 1 is of the high reliability Event Driven type, and it can be scaled horizontally. The software technologies used to implement the sub-system 1 are:

[0147] • AWS (Amazon Web Services) for columnar databases, queue systems, components for the exploitation of loT computational capabilities

[0148] • relational databases

[0149] • queue systems

[0150] • Java programming language with database abstraction libraries

[0151] • libraries for the creation of responsive and high-performance graphic interfaces

[0152] • integration services for synchronous and asynchronous communications.

[0153] Figure 3 shows a diagram of the sub-system 1 that represents the division of the subsystem into tiers and layers.

[0154] In figure 3, the number 7 indicates overall one or more concentrators to which the subsystem 1 connects. The functions of the sub-system 1 are controlled by a workflow tier indicated with 310. This is divided into the workflow layers indicated with 311, into a service layer indicated with 312 which comprises the sub-modules for the execution of planning and recording activities, and a layer for the sub-modules that manage communication, indicated with 313, and which comprise a communication manager indicated with the name Device Communication Manager, which in turn cooperates with a DLNS tier indicated with 320 and an integration manager indicated with the name Device Integration Manager which connects to the concentrator 7 as well as the DLNS tier 320. The sub-system also comprises a data tier 330 in which there is provided the storage section of the master data and activity data, indicated with 331 and 332, respectively, and a data layer is also provided to provide access to such data, indicated with 333. As far as the Master data 331 is concerned, they consist of a set of private entities specific to the sub-system 1, of which the sub-system 1 is the master, and entities common to other systems, of which the sub-system 2 of the Master Data Management type is master, and which are synchronized by the latter, in the event of changes, to the sub-system 1.

[0155] Number 340 indicates an integration tier that comprises the sub-modules relating to the integration services and to the inbound and outbound processes.

[0156] A further tier 350 is related to a Problem Manager sub-module (component 11 of figure 2) which is basically a system for the automated management of remote management problems related to the devices, whose architecture and functionality are described in detail below.

[0157] The web tier 360 comprises the software for the GUIs, GUI services and Data services, while there is provided a further tier 370 which is related to core network services and which comprises the instructions for the TLC configuration, for the management of Keep Alive services and for First and Last Gasp services in regard to field devices. These services are of a spontaneous type, the first (Keep Alive) with a fixed frequency allowing to verify the reachability of individual physical devices. The Last Gasp service is essential for recording an outage event of the physical device, allowing the central system to adequately manage a situation of unscheduled disconnection of a device. On the other hand, the First Gasp event allows to manifest the presence of a new device on the network, activating the processes for system enrolment.

[0158] MASTER DATA MANAGEMENT SYSTEM

[0159] Referring again to figure 2, the sub-system indicated with 2 is configured to define the data model, the collection, management, versioning and distribution of the data that are common to multiple sub-systems, that is, it constitutes a Master Data Management (MDM) sub-system that, through specific integration flows, synchronizes to each of the other sub-systems that are part of the invention, the only data for which each sub-system is interested in holding a replica in its local storage.

[0160] The main functionalities are therefore:

[0161] • Global Data Model: standardize the information common to the various subsystems by means of a Global Data Model, in which the descriptive entities of the company’s technical registry data (measurement points, field devices, etc.), are uniquely identified and represented;

[0162] • Data quality features: to maintain usable and accurate information, rules have been implemented in the sub-system 2 able to maintain a high quality of the datum across the entire process, from acquisition to its distribution;

[0163] • Inbound and outbound integration: the sub-system 2 provides inbound (for receiving incoming data) and outbound (for distributing outgoing data) integration services with the other sub-systems, both those internal and also those external to the system, in order to exchange updated registry data. The integration services are designed to be re-usable.

[0164] Figure 4 shows a more detailed example embodiment of the architecture of the subsystem 2.

[0165] The sub-system 2 according to this embodiment consists of the following functional blocks:

[0166] • MDM: Master Data Management 400 and Data Access Services 401;

[0167] • Wrapped CRUD Services 402: Data historicization management service. This service adopts a historicization mechanism based on the concept of bitemporalism;

[0168] • Entity Handler Services 403 : Entity Model management service;

[0169] • Business Services 404: Business process management services (e.g. Contract Activation);

[0170] • UI Service 405: User Interfaces to view and modify the data;

[0171] • Orchestrator 406: Orchestrator to manage complex registry data update (WOM) activities, which cooperates with the sub-system 5 of figure 1 ;

[0172] • Inbound and Outbound Services 407, 408 for connection to other internal and external sub-systems;

[0173] • Data Cleansing Procedures 409: Cleansing Procedures;

[0174] • BackEnd Services 410: BackEnd Services (e.g. Data Quality).

[0175] According to an example embodiment of the architecture of figure 4, the software technologies used are outlined in the following non-exhaustive list:

[0176] • Messaging and queuing system

[0177] • Oracle Cloud Infrastructure (OCI) Services

[0178] • Prevalent Java programming language with relational database abstraction libraries

[0179] • Formatting language and user interaction using HTML5 web browser

[0180] • Libraries for the creation of responsive and high-performance graphic interfaces

[0181] • Java Spring libraries for the creation of high-performance and maintainable web applications

[0182] • Scheduling system

[0183] • Relational Databases

[0184] • Application server

[0185] • Microservices based on AWS services

[0186] METER DATA MANAGEMENT SYSTEM

[0187] A further sub-system represented in the general architecture of figure 2 is the Meter Data Management System, indicated with 3 and having the role of managing all the processes related to the measurements, after the acquisition of the measurements and before invoicing.

[0188] Both HES sub-systems, the one dedicated to the low voltage networks 10 and the one dedicated to the medium / high voltage network 1, are integrated with a Measurement system 3, both the specific module of the system according to the present invention, and also another third-party system. Both allow data to be sent using the interfaces present in the destination sub-system. These peculiarities allow to: o install a single instance per module in a cloud space of the distributor regardless of the variety of physical devices in the network, without having to provide an instance for each configuration of physical devices, or o dedicate a shared but segregated cloud space (multi-tenancy), a specific configuration per module, which allows to manage the specificities of the distributor’s physical devices.

[0189] The functionalities for the execution of which the sub-system 3 is configured are mainly the following: o Meter data reception: The sub-system 3 is the centralized collector of the measurements, with multiple functionalities, some of the main ones being: Receipt of Measurements, Estimation, Technical Validation, Validation of Registries and Curves, Calculation of consumption, Energy balance, Publication of measurements and consumption to external systems and parties, calculation of any indemnities, etc. o User Interfaces for Measurement Management: In the sub-system 3 the user interface for measurement management is centralized, thus allowing to have, in a single location, access to all the data for the user who is profiled to perform actions; o Multi-tenancy: The sub-system 3 can be configured in its functionalities and in data segregation so that it can be efficiently adapted to the needs of a multi-country company with efficient operations; o Facility customization: The system is able to customize a variety of functionalities by means of a simple configuration, adapting easily to the needs of a multi-country company, for a series of customizable functionalities, such as for example, but not limited to: Measurement Reception, VEE (validation, estimation and editing), User interface, Energy Balance.

[0190] Figure 5 shows a more detailed example embodiment of the functional architecture of the sub-system 3 according to a particular embodiment thereof.

[0191] The core 500 of the sub-system according to this example provides the functional modules related to:

[0192] • Measurement reception 501, the module provides to: o Communicate requests made by the planner to external systems o Receive ACKs and measurements from external systems o Syntactically validate the information received o Provide measurements to the validation modules o Return the outcomes of the formal and syntactic validations to the external systems

[0193] • Measurement validation 502

[0194] The validation process acquires the measurements (Registers and load curves) from the upstream process “Measurement Reception”, and deals with normalizing, primarizing, and finally Validating (daily and period validation) the measurements, and subsequently sends the updates of the processed Measurements to the subsequent modules.

[0195] The Normalization, Primarization and Validation processes are different depending on the type of measurement (Registers, Load Curves).

[0196] By Normalization we mean the process that, with Measurements deriving from the field being provided as input, is responsible for processing the data and interpreting the events that occurred during the measurement of the energy by the meter.

[0197] The Primarization process is responsible for primarizing the normalized Measurements by transforming the normalized measurements, from secondary to primary, thus making them available for the validation process. Specifically, it selects all the measurements of a given meter for a certain period of time, and multiplies them by the meter’s energy constant.

[0198] After the primarization is performed, the process continues with the Daily validation.

[0199] The daily validation of the load curve has the task of interpreting the status codes identified by the normalizer and, based on appropriate configurations, applying algorithms to correct any anomalies in the load curve. After correcting the load curve, it will be valid and available for subsequent processes.

[0200] After performing the Daily validation, the system applies the periodic Validation to the measurements.

[0201] The periodic Validation of the Registers applies Consistency and Plausibility checks on the period.

[0202] By periodic Register Validation we mean working the End of Period Registers, previously processed by the Daily Register Validation process, to allow the periodic Validation of the Load Curve. The process of validating the daily registers triggers the process of validation of the periods of a Load Curve.

[0203] Period validation deals with validating a measurement for a given period. By “periodic validation” we mean a comparison between the consumption recorded by the load curve, in a given period, and the consumption recorded by the registers for the same time period.

[0204] If the value between the Register Consumption and the Load Curve Consumption does not match, methods for the Correction of the Load Curve are applied.

[0205] • Energy reconstruction 503

[0206] A module that allows to apply different methods for reconstruction of the energy in the face of the detection of an anomaly or fraud

[0207] • Calculation of estimates 504

[0208] This module deals with providing methods for estimating missing or anomalous energies.

[0209] For each type of supply, depending on the characteristics of the measurement point and the configurations, one or more estimation algorithms with configurable priorities can be applied. • Measurement management using web tools 505

[0210] Web app that allows to visualize, manage and modify measurements (registers and load curves)

[0211] • Manual entry procedures 506

[0212] • Pre-invoicing checks 507

[0213] • NTL (Non-technical Losses) functionality 508.

[0214] Storage areas 509, 510, 511 are provided for readings, hourly consumption and consumption on a non-hourly basis, respectively.

[0215] In section 520 there are provided functional modules related to:

[0216] Complex points 531, Integration Layers 532, WPWPC (Withdrawal Point Withdrawal Partition Coefficients) 533, Energy Balance 534, Transmission and Publication 535, VMC (Verification of Measurement Complexes) 536, cost determination 537, Business Readings (BR) 538, Reporting Functions 539 and Reading Planning 540.

[0217] As shown in figure 5, the sub-system 3 receives data from external remote reading systems 550 and from Master Data systems 560. In addition, the sub-system 3 communicates bi-directionally with external systems relating to invoicing systems 570, commercial areas 580 and control and intervention members 590.

[0218] The functionalities described for the sub-system 3 are provided by the following technologies and middleware:

[0219] • Columnar databases

[0220] • Standard Messaging System and ultra-high-performance distributed messaging system

[0221] • Relational databases

[0222] • Ultra-high-performance distributed file systems

[0223] • Very large log collection and management component

[0224] • Prevalent programming language Scala and libraries for the creation of high- performance and responsive graphical interfaces

[0225] • Workflow scheduling system

[0226] • Ultra-high-performance data processing component

[0227] • Synchronous and asynchronous integration components

[0228] WORK FORCE MANAGEMENT SYSTEM

[0229] The sub-system 4 of figure 2 is a Work Force Management type system that deals, from a functional point of view, with managing the planning, the optimization of routes and the assignment of work orders in the field, the execution by means of dedicated Smartphone apps, and the consolidation of the technical and accounting data associated with the activities performed.

[0230] The main Functionalities are:

[0231] Work requests acquisition: The application deals with managing all the work requests sent by the work order management sub-system 5, specializing the attributes necessary for the next planning;

[0232] Automatic scheduling: The application allows to plan activities by optimizing the routes that connect the various sites where the field work is to be carried out and the teams of operators to be assigned. The module also allows to model simulations in order to find the best configuration. In addition, the module allows to use different planning optimization engines, even third-party ones, thanks to the fact that the optimization logic is isolated in a separate sub-module, which communicates with the scheduling module by means of well-demarcated interfaces;

[0233] Mobile: The sub-system, called ForceBeat Mobile Suite, comprises an entire suite of mobile applications that runs on smartphones assigned to each operator.

[0234] Figure 6 shows a particular example embodiment of the technical architecture of the sub-system 4. The section 600 comprises the server module which has, like other modules, its own GUI 601, the modules for running presentation services 602, the core business logic service modules 603, and an access services module 604. The latter accesses the data layer of the sub-system 4 which is indicated with 605. The Core Business logic module controls a device synchronization services module 606, a path optimization engine 607, and an external systems integration services module 608. The server in turn interfaces with the mobile suite 609 which is structured, for example, as described below with reference to figure 12. The mobile suite consists of several reciprocally independent apps that in the example consist of an app that generates the work list indicated with 610, external apps 611, apps for vertical processes 612, crosscutting apps 613 that provide services for various apps of the mobile suite 609, and accounting consolidation apps 614.

[0235] MOBILE SUITE

[0236] The mobile suite module is able to support all the activities to be performed in the field by means of a modular architecture that follows the same setting used for the implementation of the system according to the present invention “server side”. Where the system according to the present invention is organized according to sub-systems, some of which with vertical process functionalities (meter data management, work order management, etc.) and others with cross-cutting process functionalities (AAA subsystem, master data management sub-system), also in the case of the mobile suite there are apps with specific functionalities and apps that offer functionalities / services that cross-cut the others. The apps are created so that each app is responsible for a specific type of activity in the field, as opposed to the traditional “monolithic” approach in which the AMI / Smart Metering suites have, in their Work Force Management component, a single mobile application for performing activities on the meters. Having a plurality of apps as opposed to a single app allows to isolate changes so that, in the face of new requirements or corrective changes that impact only one type of activity, the impacts are isolated to a single app, leaving the others unchanged. This brings the following benefits:

[0237] • It allows to reduce total testing time, since non-regression tests will be limited to the modified app only and not to a monolithic app that includes all the functionalities;

[0238] • It allows to reduce app rollout times on all smartphones, since the impact on the set of functionalities available to the smartphones is limited to a specialized app and the specific type of activity it manages;

[0239] • It allows to limit the risks related to functional, performance or safety problems discovered only in the production environment, since they are confined to a specific application that impacts only one type of activity.

[0240] With all the vertical process apps of the suite, the user can work in both online and offline mode, thus guaranteeing operation even in the absence of connectivity.

[0241] An embodiment of the mobile suite is shown in figure 12. This non-limiting example shows a mobile suite that consist of the following apps:

[0242] • WOL - work order list: synchronizes all activities to be performed of all types between the server sub-system and the smartphone, and once performed it synchronizes the outcomes to the server; provides the operator with a single access point with the list of field work to be performed

[0243] • ME-CE - programming activities on low voltage meters

[0244] • ME-RE - acquisition of the meter’s readings and load curves

[0245] • ME-VE - testing of measurement complexes

[0246] • ME-LM - mass readings through Power Line Communication • ME-GE - customer reported failure management by means of the distribution company’s outage management system

[0247] • ME-FA - management of failures identified by operators during field work

[0248] • ME-GM - activities on medium / high voltage meters

[0249] • ME-WO - inspection and preventive activities

[0250] • ME-CA - distributor’s complex activities

[0251] • ME-CC - activities on concentrators and associated communication modules (modems, routers)

[0252] • ME-LI - inspection and analysis activities along low voltage distribution lines

[0253] • ME-LM - mass readings through Power Line Communication

[0254] • ME-DI - accounting balance of activities performed, hours worked, materials used for internal and external staff

[0255] • ME-HR - administrative balance of holidays, permits, etc. for the distributor’s internal staff

[0256] • ME- SI - seal management

[0257] • Cross-cutting / Service APPs

[0258] • SM-PR - contains the logic for generating electricity meter programming commands for apps that can communicate automatically with the field devices (meters, concentrators, etc.)

[0259] • SM-DP - attachment management

[0260] • SM-DM - document electronic signature management

[0261] • SM-TU - utilities and basic tools

[0262] • MDM - user data entry management

[0263] All mobile apps are accessed through a Single Sign-on mechanism enabled by an additional external AAA cross-cutting app with which all the apps of the mobile suite are integrated.

[0264] In addition, the apps are integrated with an additional external app for mapping the distribution network, which allows to transparently switch from the visualization of the field devices on a geographical map with the distribution network overlaid, to the visualization of the activities to be performed on the same devices.

[0265] WORK ORDER MANAGEMENT SYSTEM

[0266] The sub-system 5 represented in figure 2 is responsible for the generation and management of the electricity distribution company’s work orders, whether they are of a commercial or technical nature, to be carried out remotely through remote management (through the sub-system 1) or locally by field operators equipped with smartphones provided with the apps of the Beat Mobile Suite (part of the sub-system 4).

[0267] A detail of the organization of the Software of the sub-system 5 is provided in figure 7.

[0268] The WORK BEAT application, that is, the sub-system 5, consists of many modules that contribute to the realization of the multitude of processes of a DSO’s work. The modules responsible for implementing the processes that contribute to the realization of the business processes are summarized at a logic level in the blocks represented in the Business Logic Layer 710, some of which are shown in figure 9 and identified by their name:

[0269] BPMACQ: the module is responsible for defining the process and sub-processes for capturing the request for utility management activities.

[0270] BPMCANC: the module is responsible for defining the process for canceling a request for a utility management activity.

[0271] BPMCDES: the module is responsible for defining the process for managing the accounting data for activities belonging to campaigns.

[0272] BPMCDSH: the module is responsible for defining the process for managing campaign activity batches. The main processes managed are batch creation, batch state machine management, receiving notifications of batch activities.

[0273] BPMCOMIT: the module is responsible for defining common sub-processes.

[0274] BPMDES: the module is responsible for defining the process for assigning utility management activities, and checks and arrears management activities.

[0275] BPMFMA: the module is responsible for defining the processes that allow to interact with the field activities scheduling system. There are different defined processes: management of work order data communication, process for managing work order progress notifications, process for managing work order execution data, process for managing the upload of documents attached to a work order, process for managing the revocation and cancellation of a work order.

[0276] BPMFAT: the module is responsible for defining the processes that allow to submit the final balance for a task performed to one or more requesting systems.

[0277] BPMGITG: the module is responsible for defining process and sub-processes that realize the lifecycle of the concentrator management activities. BPMHESM: the module is responsible for defining the process and sub-processes that realize the management of communication with the remote management system of low- power electricity meters. The processes managed are the following: work order communication, work order notification management, work order revocation and cancellation management.

[0278] BPMRISG: the module is responsible for defining the process and sub-processes that define the process for managing fault reporting activities, the processes defined are the following: creation of the fault reporting activity, management of work order progress notifications, communication of execution results and closure of the fault reporting activity.

[0279] BPMRSPR: the module is responsible for defining the process and sub-processes that define the process for managing the inspection and quotation activities.

[0280] BPMSWTC: the module is responsible for defining the process and sub-processes that define the process for managing commercial switch activities.

[0281] BPMUES: the module is responsible for defining the process and sub-processes that manage the updating of registry data and the validation of the work readings.

[0282] BPMWDV: the module is responsible for defining the process and sub-processes that manage the controls on work execution data, manage Back Office activities, and manage the blocks.

[0283] The modules responsible for implementing the logics that are used by the processes within each execution step are summarized by the blocks represented in the Business Logic Layer 700. Each of these entities can have its own set of entities within the persistence layer 720.

[0284] The modules that realize technical functionalities to support the system can logically be placed within the Integration Layer 730.

[0285] The modules that offer cross-cutting security, audit, and tracking functionalities make up the cross-cutting layer 750.

[0286] The particularity of the Work Order management sub-system 5 is to define modules that, depending on the process, can be specialized in the management of the process itself or can be more generic and contribute to the implementation of the process itself and of other processes. A detailed explanation is provided on how the processes are realized and how the sub-system’s modules dialogue for each type of process. For the following types of processes, user device management, arrears management, verification of groups of measurement complexes, the modules and the interaction flow between them are as follows:

[0287] 1. Activity requests are received by the acquisition module (BPMACQ). This carries out the admissibility, correctness and validity checks to accept or reject the request. In the event it is accepted, one or more activities are created, using the data of the request and those present in the registry, and all the calculations are made to determine the operation to be performed on the meter and the executing system. Subsequently, it is verified if the activity can be assigned to the executor or if there are conditions to link the activity. If it is possible to proceed, control is passed on to the next module, as a function of the executor: field execution as per step 2, remote execution for low voltage meters as per step 3, remote execution for medium and high voltage meters as per step 4, administrative activity as described in step 6.

[0288] 2. In the case of an activity assigned to a real executor in the field, the assignment module (BPMDES) is started. The module has the task of performing the following types of calculations: calculating the user device management algorithm, calculating the type of executor, calculating - if necessary - the executing company, finding the last reading present in the measurement system. In the case of orders on request or with quotation, it interacts with the accounting system to report the request for data and obtain a response. Subsequently, control is given to the module that manages communication with the field activities scheduling system, as described in point 5.

[0289] 3. In case of activity assigned to the low voltage meters remote manager (BPMHESM). The module is responsible for calculating the scheduling window, the scheduling sub-windows and any additional data useful for the execution and preparation of the activity request. Subsequently, the module waits for notifications of the progress of the activity and the outcome of the execution. Once the execution outcome is received, the following possibilities can occur: the activity is cancelled and the process flow is closed, a negative outcome is received and the activity is assigned to the scheduling system by recalling step 2, or a positive outcome is received, and the data is validated as per step 6.

[0290] 4. In case of activity assigned to the medium and high voltage meters remote manager (BPMPPHESM). The module is responsible for calculating the operations to be performed and the data useful for the execution. Subsequently, the module waits for notifications of the outcome of the execution. Once the execution outcome is received, the following possibilities can occur: a negative outcome is received and the activity is assigned to the scheduling system by recalling step 2, or a positive outcome is received, and the data is validated as per step 6.

[0291] 5. The BPMFMA process manages communication with the scheduling system. The module is responsible for retrieving the activity data and sending the work order request. Subsequently, the module waits for notifications and for the outcome of the execution. Once the execution outcome is received, it is possible to proceed with the validation of the execution data, as described in point 6.

[0292] 6. In the event of activity performed, administrative activity or closure of activities in CBO, the data validation module (BPMWDV) is activated, which performs the completeness and correctness checks of the execution data, verifies the synchronization of activities on the same measurement point and, in the event of a positive outcome of the checks, the execution data is copied into the corresponding entities. In case of data problems, the corresponding block available to the end user is opened in order to correct or modify the data. If all the blocks have been closed, the process continues to the next step, described in point 7.

[0293] 7. The BPMUES module is activated, whose task will be to update the registry system and send the work readings to the measurement system. The steps performed are as follows: the activity data is retrieved, the need to update the registry is verified, if this is necessary, the registry update scenario is determined with all the services. The request for registry update is sent and, if the outcome is positive, the readings are managed. If the outcome is negative, a block will be opened which will have to be resolved with data remediation or data changes. The work readings are recovered, and the request message is sent to the measurement system, the outcome of the validation is awaited. If the outcome is negative, the corresponding block is opened, waiting for the readings in the measurement system to change, if the outcome is positive, the process proceeds to the next step, which is described in point 8.

[0294] 8. The BPMFAT module is activated, which is responsible for completing the process by informing the requesting system of the outcome of the execution of the activity. The process carries out the following operations: it verifies whether it is necessary to create additional technical activities on the measurement point, it retrieves the activity execution data and sends the outcome to the requesting system. The response is awaited and, in the event of a positive outcome, the final activities are performed, while in the event of a negative outcome, a solution to the problem is awaited.

[0295] Once these steps have been completed, the process can be declared complete in its entirety.

[0296] Figure 9 shows three examples of execution flow for different types of work orders, showing the sequence of involvement of the different functional modules.

[0297] The information technologies used in this sub-system are:

[0298] • Relational databases

[0299] • BPM workflow execution and orchestration engines

[0300] • Application and Web Server

[0301] • Java predominant language with database abstraction libraries and utilities

[0302] • Libraries for the creation of responsive and high-performance web applications and graphic interfaces

[0303] • Components for managing large application logs

[0304] • Internal messaging system

[0305] AMI HEAD END SYSTEM - MV / HV METERS

[0306] Figure 8 shows the detail of the AMI Head End sub-system for medium and high voltage meters.

[0307] The HES sub-systems dedicated to integration with the field devices are differentiated by the voltage level measured by the devices themselves. This differentiation allows to support the different types of network characteristic of the level of voltage distributed. The low voltage level has a large number of installations (32 million meters) and a certain uniformity in the technology of the devices with which to dialogue. The medium / high voltage level has smaller orders of magnitude (150,000 meters); however, the communication technologies and protocols of the devices are heterogeneous.

[0308] Both HES sub-systems allow to operate with different technologies and protocols, and with different hardware and software versions of the devices themselves. In the case of the HES for medium / high voltage meters, this possibility is evident in 810, where the PPNS component can be integrated with the drivers specific for each MVM (Medium Voltage Meter) to be integrated. In addition, the module that operates on low voltage networks can perform the software update activities of the devices themselves. The main functionalities are:

[0309] • Remote Meter Management: remote management of the software and parameters of the meters through administration, authentication and authorization consoles.

[0310] Management functionalities concern:

[0311] • technical data

[0312] • calls and connections (GSM and GPRS)

[0313] • remote management functions

[0314] • online manual functions

[0315] The architecture of the sub-system highlighted, shown in figure 8, shows the analogies with the macro-architectures of the sub-systems according to figure 1. This sub-system also has its own GUI 108, UI services 208, logical applications 308, integration services 408 and a data layer 805.

[0316] Similarly to what is shown in figure 1, the integration services interface through the company services bus 8 with external systems.

[0317] The data layer 805 is accessible by means of data access services 806.

[0318] Backend services indicated with 807 are also provided.

[0319] The application logics 803 comprise modules intended to provide different management functionalities, and among these there are provided modules relating to remote device drivers and mobile device drivers, as indicated with 808 and 809, which communicate with a remote communication module 810 for bidirectional connection with the medium voltage meters 10 (MVM) and with a backend services module 811 with the mobile units 6, respectively. These modules are also provided in combination with integration services 812 and access services 183 to a data layer 184.

[0320] According to one embodiment, the computer technologies used for the implementation of this sub -system 10 are

[0321] • Relational databases

[0322] • Workflow execution and orchestration engines

[0323] • Application and Web Server

[0324] • Java predominant language with database abstraction libraries and utilities

[0325] • Libraries for the creation of responsive and high-performance web applications and graphic interfaces

[0326] • Components for managing large application logs

[0327] • Internal messaging system • Scheduling system

[0328] • Synchronous and asynchronous integration components

[0329] • Proprietary components for de / coding the low-level commands and data of the devices

[0330] • Columnar databases

[0331] SUB-SYSTEMS OFFERING CROSS-CUTTING SERVICES

[0332] The sub-systems offering cross-cutting services are shown in the lower part of figure 2.

[0333] The sub-system 12 is a system for the centralized management of SSO and AAA for all sub-systems; the sub-system 13 offers portal and navigation services and combines all the individual Web interfaces of the individual sub-systems into a single work environment for users; the sub-system 14 is a sub-system that provides real-time monitoring services to all sub-systems; the sub-system indicated with 15 is a sub-system that provides reporting and analysis services to all sub-systems.

[0334] These sub-systems, similarly to what provided for the sub-systems described in detail previously, are also constituted by and configured as independent software sub-systems, and the architectural characteristics of the sub-systems described in detail extend to them.

[0335] DUAL TECHNOLOGY SYSTEM METER ENROLMENT

[0336] The sub-system performs the use cases described above, which are all essential for having an exhaustive set of remote management processes; however, the sub-system excels in scalability and in hourly and daily performance in reference to very large volumes of installed devices, exceeding 30 million electricity meters. To achieve these volumes, guaranteeing the performance indicators set forth in the reference market, innovations have been implemented at the technological level in infrastructure and application code. The sub-system is based on two communication and transmission technologies, used in a combined manner: the Power Line Communication (PLC) channel, and the Radio Frequency (RF) channel. The PLC channel allows transmission, preferably two-way sending and receiving of data, over electrical cables that physically connect meters and concentrators. Each concentrator is served by dozens of, rarely a few hundred, meters, which transmit, by means of conveyed waves, the data regarding withdrawn and inputted energy. The commands that the concentrators give to the meters and the corresponding responses also travel through this channel. This channel is reliable, but does not allow for easy interventions aimed at improving signal quality in the event of interference, and it is not flexible: the link between the concentrator and the meters is physical, defined by the electricity network’s electrical connections.

[0337] RF was introduced following different approaches, depending on the type of underlying electricity network. In one case, once the near-maximum optimization level of the PLC transmission was reached, the RF transmission channel was also activated, which introduced the flexibility and performance necessary to easily exceed the performance levels imposed by the reference market. In practice, at the end of the day, when everything that can be collected as data and commands via PLC has been acquired, the residue is recovered via RF through a dedicated process that therefore allows to collect everything that could not be collected via PLC, increasing each day’s performances by a few percentage points. In another case of the technology’s application, where the quality of the PLC signal is affected by electromagnetic interference and “Chorus” effects of interference between concentrators have been found, the RF channel proves to be optimal, allowing to use dynamic configurations in order to find the best meter-concentrator association and transmit data and commands.

[0338] The concentrators and meters are provided with a processing unit with a memory in which a communication program is loaded, which contains the instructions to make said processing unit capable of performing the following steps:

[0339] • Monitor the communication functionality toward each of the meters associated with a concentrator through the electrical distribution line and by means of the radio frequency transmission units (hereafter understood as two-way);

[0340] • Use cable communication when the transmission by means of the radio frequency transmission units is not functional, or vice versa,

[0341] • Provide that, with at least one second concentrator that is provided with a radio frequency transmission unit, there are associated, or able to be associated, alternatively one or more meters that are mainly associated with a first different concentrator, and automatically activate communication by means of the radio frequency transmission units with the second concentrator when the functionality for communicating by means of the electrical energy distribution line and by means of the transmission units between said meter and said first concentrator is compromised or not present. The aforementioned association takes place through the enrolment process. This process provides to code and store the links between concentrators and meters. In the case of RF transmission, the system continuously monitors the signal quality between concentrators and meters. The system therefore proposes enrollment and de-enrollment actions based on signal quality. Enrolment action is required in order to provide the concentrator involved in the process with the encoded keys for access to communication with the meters, so as to have secure communication.

[0342] Figure 15 shows the difference between:

[0343] • The enrollment process in the AMI according to the state of the art, figure 15 a), wherein each meter 1500 is associated with a single concentrator 1510, the one physically connected to the meter 1500 by means of a low voltage power line 1520. The communication of the concentrator with the HES sub-system 1550 takes place via a mobile radio network;

[0344] • The enrollment process in the AMI according to an embodiment of the present invention, figure 15 b), wherein each meter 1500, in addition to being associated with the “parent” concentrator by means of the Power Line Communication channel, is also associated with one or more concentrators 1510 by means of the RF channel 1530.

[0345] Furthermore, for data transmission between field devices and management system according to the present invention, the combined use of planned mode (scheduler and SFTP) and spontaneous mode (AWS and MQTT Services) data transmission has been introduced. In planned mode, execution windows are defined for the transmission of data requested by the concentrators, while in spontaneous mode the concentrators act independently, initiating transmission when faced with a significant amount of data. To enable this mode, software components are deployed on the concentrator systems which are dedicated to calculating the opportunity to spontaneously send measurements of energy absorbed and fed into the network by means of the meters and proceed with the transmission of this data toward the central system, saving the time that would have had to pass between one scheduling and another.

[0346] The combined arrangement of the PLC / RF transmission between the meter and the concentrator, and the planned / spontaneous mode between the concentrator and the central system allows to exceed the performance threshold for the acquisition of data regarding the energy withdrawn and fed, required by the reference market, by several percentage points.

[0347] PROBLEM MANAGER

[0348] The sub-system 1 provides a Ticket Management service by cooperating with a subsystem indicated with 11 in figure 2.

[0349] A further tier 350 is related to a Problem Manager sub-module that is basically an automated ticket manager: it consists of a configurable rules engine that allows to activate, in the face of error codes found in the execution of remote management activities by the sub-system 1, a sequence of corrective actions that can be of a manual nature (displaying the errors on an operator screen) or automatic (e.g. automatically creating and / or performing, remotely, SW update activities or technical reprogramming activities of field devices, or creating and sending activities of replacement of faulty meters to the Work Order Management sub-system). Thanks to this module, it was possible to increase the percentage success rate of remote management operations in a purely automated way, minimizing human personnel intervention time.

[0350] The basic operation of problem management consists of three moments:

[0351] • Problem detection. The problems that arise on the meters and concentrators can be isolated, that is, divided into groups correlated to each other on the same network device or on different devices, united by the effects of the problems themselves. On a daily basis, there are millions of this type of events generated on a large distributor. In order to be able to process them, Big Data type data processing technology is used and, using processing algorithms that exploit MapReduce techniques, the status that the tickets have to assume and the parameters of the decisions to be made are defined.

[0352] • Decision processing. The system processes the events recorded by mapping unique codes and event identification codes. The system can be configured to allow to define remote intervention strategies and local intervention strategies, according to the context. Such strategies encode the experience of experienced operators in terms of repeated actions, recovery attempts, time intervals, sequences of operations.

[0353] • Action execution. The system sends commands to the other modules and to external systems for the execution of recovery operations.

[0354] The greatest effort in adopting this system is being able to maximize the Problem Manager - Automatic Correction Action - Head End System - Work Order Generation flow of figure 14. This is the mode that allows to deal with the volumes of problems encountered in the reference market with very low costs (machine time and telecommunications channel use).

[0355] As shown in the drawing, the HES sub-system 1400 allows to detect certain events 1410. An extractor 1420 examines the events and performs the opening or closing of a ticket 1430. The ticket is supplied to the Problem Manager module 1450. The ticket 1460 is managed manually or automatically, and the information on the effects relating to the ticket being worked is provided to the HES system. This provides to generate a work order 1470 that can be related to automatic activities to be performed by means of intervention with personnel or to be performed by means of automated procedures guided by a software that defines the intervention modes.

[0356] To pursue this maximization result, guaranteeing efficiency, the AMMExtractor software component 1420, present in figure 14, was created, which accesses a columnar noSQL big data database and interprets a large number of events using mapReduce algorithms, and synthesizes one or more problems thereof, directing these problems toward the ticket management 1430 of the Problem Manager 1450. The core components of the Problem Manager 1450 have the ability to decode state words, which indicate the elementary state of the objects that make up the electronic part of the electricity meter. From these state words it is possible to infer, for example, if the markers are reliable, or if a tampering attempt has been made, or if there are suspected hardware failures. In figure 14, the basic flow is completed with automatic or manual actions 1460, toward the remote manager 1400 or toward other sub-systems, either internal or external to the management system. The procedure to be followed for each type of event-problem is encoded in the core and the Problem Manager 1450 acts as a robot.

[0357] The set of these innovative elements: state machine, interpretation of state words, mapReduce processing on big data, has allowed to put in place an extremely effective and efficient tool in the automatic resolution of a distributor’s problems.

[0358] As an example, figure 13 shows a typical example situation, as stated, completely configurable according to the characteristics of the electricity network managed, which affects the data transmission capacities and the resistance of the devices of the network itself. Last but not least, the telecommunications network adopted and the telecommunications devices in use, which differ from distributor to distributor and between segments of the network of a same distributor, require similar interventions of restoration and configuration, and remote or local interventions. The system is equipped with hundreds of diagnostic actions and codes, with different configurations depending on the network which the system interfaces with.

[0359] EVENT ARCHITECTURE AND CONSOLIDATION FOR MASS REMOTE MANAGEMENT ACTIVITIES

[0360] The HES sub-system 1 has inside it an architecture developed specifically to manage large volumes of requests to the concentrators (multiple requests per day for each concentrator, for large distribution companies with customer numbers in the tens of millions) maximizing the consolidation of requests intended for meters serving the same concentrator, while allowing urgent requests (with a shorter execution deadline) to be executed with priority. The architecture provides to divide the processes that provide for communication with the concentrators into elementary requests. The requests are processed individually (one request per meter) in an event-driven mode by the different sub-modules that interact with each other through asynchronous queue-based interfaces in order to maximize horizontal scalability; the requests are consolidated by concentrator only shortly before being sent to the concentrators themselves. In order to minimize the risks of data loss in the event of a failure of a queue or of a message consumer, the data that make up the message payload are not included in the messages themselves but persisted in databases, and referenced within the messages.

[0361] The process of remotely executing the requests for activities on the meters consists of the following use cases, each implemented by a sub-module of the sub-system 1. A representation of the process is given in figure 11 :

[0362] • Enter CMO, indicated with 100: this is triggered by the Work Order Management sub-system of the sub-system 5, creating the remote work order for a single meter 17;

[0363] • Execute Remotely CMO: coordinates the life cycle of the execution of the remote work order, integrating with the DCM sub-module that physically manages communication with the field devices. It is divided into two components: o Module A 110: identifies the concentrator to which to send the request and the communication channel to be used; generates the commands of the protocol used by the concentrator concerned; finally, activates the DCM module to trigger communication with the concentrator; o Module B 12210: manages the result of the communication returned from the DCM module 314, decoding the responses according to the protocol used by the concentrator 7 and extracting the relevant data for the running processes;

[0364] • Acquire CMO execution Data 130: returns the remote execution result to the calling sub-system;

[0365] The following use cases are realized within the Communication Layer 313:

[0366] • DIM Enter Asynchronous Meter Request 140: has the task of scheduling communication activities with the concentrators 7 by consolidating the requests intended for meters 17 that serve the same concentrator 7, and of managing the prioritization of requests so that more urgent work orders (e.g. reconnections) are not in a queue behind less urgent work orders (e.g. reschedulings or mass readings), with the risk of being executed after the regulatory deadline. The UC calculates the maximum waiting time of the single request based on the priority (maximum waiting time inversely proportional to priority), it verifies the existence of a communication reservation for that same concentrator within the maximum waiting time, and if it exists, it aggregates the request to the reservation (box group of requests pertaining to the same concentrator) found, otherwise (box does not exist or a box exists for the same concentrator but with longer waiting time) it creates a new box, scheduling it compatibly with the maximum waiting time. If a new box is created, it activates the UC DIM Execute Communication 150 for that box.

[0367] • DIM Execute Communication 150: performs all the activities of the box, forwarding the commands of the various aggregated activities to the concentrator using the remote communication channel selected for the specific concentrator (e.g. 4G mobile radio communication). Finally, it activates the UC Watch Box 160

[0368] • DIM Watch Box 160: verifies if all box activities have received responses from the concentrators. If an activity has received all the expected responses, it closes it and returns the response to Module B 120 of the UC Execute Remotely CMO. The same occurs for activities that did not receive all the responses but have expired. If, on the other hand, there is at least one request still open and not expired for that box, it activates the UC Execute Buffer Download 170 in an attempt to download the missing responses, and it activates itself by setting a delivery delay.

[0369] • DIM Execute Buffer Download 170: downloads the response buffer from the concentrator 7 by means of remote connection using the communication channel of the specific concentrator. It identifies the responses received and reconciles them with the requests submitted on that concentrator for the different activities performed.

[0370] CENTRALIZED SYSTEM FOR WORK ORDER MANAGEMENT AND MASS REPLACEMENT CAMPAIGN

[0371] Centralized work order management

[0372] Within the context of the systems that realize an Advanced Metering Infrastructure, based on current literature, there is not an explicit description of a system whose first responsibility is to implement and orchestrate the processes that involve work orders executed on field devices or elements / portions of networks whose management falls within the scope of an electricity distribution company, orchestrating all integrations between the systems that contribute to the execution of the process and monitoring its execution throughout the entire lifecycle. In traditional implementations, in the absence of this process orchestration and management system, the execution of a work order is fragmented among the many systems that participate in its execution, without there being a “supervisor” system that gives a unified overall view of all the types of work in progress. In fact, the traditional approach provides that each system “issuing” work orders (commercial system, fault management system, AMI Head End systems, network maintenance systems) issues its own work orders, which are then executed by “executing” systems (AMI Head End if the work can be performed through remote management, WFM system if the work has to be performed locally), and accounted for downstream of the execution on the issuing systems and on the systems that manage accounting. Traditionally, the end-to-end execution of these processes is not orchestrated, and each participating system monitors the execution of the portion of the process which it participates in; at most, the requesting system is notified through events by the other participating systems of the progress of the status of each work order it has requested. However, there is no centralized management of all the work orders that allows to define priorities and precedence between work order issued by different systems, there is no orchestration of the process, there is no end-to-end monitoring.

[0373] The work orders management sub-system has been designed to fill this gap by applying Business Process Management technologies for the centralized and end-to-end management of all types of work that a distribution company has to perform, whatever the system that issues the work order requests and whatever the mode of execution (remote management or field). This sub-system integrates with the other components of the Beat suite and with all the external systems of the distribution company that participate in the implementation of the work order processes, allowing to monitor in extremely fine detail each process step of each individual work order.

[0374] Building the sub-system around a BPM (Business Process Management) engine allows to obtain different benefits in the distribution company’s areas of interest.

[0375] Improvement of functional analysis and process design operations: it is possible to design the business processes of the DSO through BPMN modeling tools by experts in the field of processes, and in parallel proceed with a software development that is as adherent as possible to the process itself through tools capable of translating the BPMN diagram into SW source code, which has to be “completed” by the development team through the instructions necessary to complete the implementation (e.g. access to databases, integrations with other systems). With this approach, the distributor is able to have greater assurance that the SW developed meets the outlined requirements, especially in a context such as that of work processes that are extremely complex due to the high number of participating systems. In addition, the supporting tools allow to achieve a significant reduction in total implementation times, facilitating modeling, automating part of the code generation, and assisting in the testing phase through real-time visualization on a BPMN diagram of the process instance being tested.

[0376] Process control and monitoring: thanks to the innovative tools implemented in the subsystem 5, it is possible to identify each instance of one of the processes realized relating to a particular practice or activity. This allows to know exactly where it is located, within the process diagram, and what has happened to each work order, significantly simplifying control and monitoring activities, both in the case of simple consultation for operational purposes, and also in the case of verification by internal or external audit offices, as well as for determining a problem following internal reports or complaints from end users. The level of detail provided is such that there is the ability to determine exactly where the work order is located and, thanks to the monitoring tools created, it is possible to inspect the value of each datum of the work order at each step of the process, including the values that the data has taken in the process steps already passed. In addition, it is possible to retrieve aggregated information regarding all instances of a same type of work order. All this is done by means of a single dashboard that allows the user to carry out a search starting from the keys that uniquely identify a work order, and to visually navigate the process instances with the possibility of interacting with the image presented, exploding the individual activities of an end-to-end macro-process into sub-processes that can be searched and explored with the same functionalities.

[0377] Architectural homogeneity and adaptability: the introduction of the BPM engine has made it possible to create a clear and understandable logical architecture of the system, in which all processes are modelled and managed within the same sub-system, with the consequent possibility of quickly adapting its configuration to different distribution companies, as a function of their needs in terms of managed processes and expected volumes of activities.

[0378] High performance with respect of regulatory KPIs: the sub-system’s architecture provides that the BPM engine that contains the execution logic of the processes flowcharts works along a series of services that are invoked by the BPM engine in order to carry out the different steps included in the flowchart itself. These services are executed on dedicated and horizontally scalable application server instances: this allows to separately modulate the amount of HW resources that have to manage the pure sequence of execution of the process steps, from those that realize the internal logic at each step, optimizing operating costs and guaranteeing the expected performance. This is an important benefit for those distributor processes that are highly massive in nature, for example those related to device mass replacement campaigns, device reading, or device reprogramming. The recent regulatory requirements produced by the regulatory authorities in Italy (ARERA Resolution 87 / 2016) define the obligation on the part of distributors to perform all these actions with very strict time constraints and success rates to protect end users, and the WORK BEAT system, that is, the sub-system 5 has made it possible to comply with these regulations.

[0379] Mass Replacement Campaign

[0380] The work order management sub-system also has a logic module dedicated to the management of work campaigns on the electricity meter. Distribution companies need to carry out dedicated campaigns for different types of work that can concern: the mass replacement of meters in the event devices are changed for technological renewal (e.g. transition from electromechanical meters to smart meters, or replacement of one generation of smart meters with the next one), the reading of the meters in the event the meters cannot be reached, or mass reprogramming for reasons related to the obligations imposed by the regulatory authorities or for operational needs.

[0381] The sub-system allows to manage a work campaign in all its most critical aspects: correctly configure the type of work required, select according to different search parameters (territory, type of supplies, type of device, type of contract) the measurement points for which to issue the work order, define the batches of activities (groups of activities) that have to be correlated to each other, automatically define the assignment of activities to designated executors, keep track of the variation of each batch of a campaign and allow the operator to always have the progress of the batches in real time, define a particular mode of integration with the work order accounting management systems and define a set of standard data to allow each reporting system to use or consult the campaign data.

[0382] The campaign for managing the meter replacement works carried out by the campaign management module is realized through a series of main functionalities. The user can use a batch creation functionality with which to set filters that allow to identify the measurement points on which it will be possible to issue the meter replacement work orders, the available filters are related to the territory to which the measurement point belongs, the type of measurement point, the type of supply contract, the supply power levels, the type of meters installed and the use provided for these supplies. There is also the possibility of directly uploading a file containing the list of PODs on which to try to create the activities, even if the filters are not set.

[0383] Once this step is completed, the system allows to identify the work that will make up the batch and proposes the user consult the number of PODs included and the list of those excluded. The user can, at this point, decide to set the batch activation dates and conclude the operation by creating the batch itself. The batch status management functionality will periodically evaluate the conditions and, on the date of activation of the batch, the status will be changed and the requests for the creation of the activities will be launched, which will proceed in complete autonomy and will inform the batch of any change in the status of the activity. The user can always consult the status of the batch and the activities that make up the batch through the search functionality, this allows to search the batches by batch identifier, batch status, batch type, batch name and creation dates. Once the search result is obtained, it is possible to view: the batch’s salient information, the contractual data relating to the batch, the complete list of the activities that are part of the batch with their status. In addition, it is possible to download different files: one containing the list of batch activities with all the information for each of them, one containing the complete list of activities performed, one containing the complete list of canceled activities, another containing the complete list of activities in progress but not yet performed.

[0384] The system, through the aforementioned batch status management functionality, periodically checks the progress of the activities that make up the batch and in the event that all the activities of the batch are performed and / or canceled, the batch passes to a final status, allowing to define its closure.

[0385] There is also the possibility to cancel the batch, both when it is active and also when it is being generated. In the first case, the cancellation will only affect the batch itself, while in the second case, the activities in progress that have not yet been performed will also be cancelled.

[0386] The management of the batch’s contractual data, that is, the integration with the accounting systems, is managed by a sub-module that allows to send a single request for each batch containing the batch’s data and its composition in terms of activities, this happens the moment all activities are generated. The system that deals with accounting at that point will be able to supply the accounting data and also the company that will have to carry out the work.

[0387] Determining the performance of the companies that will have to carry out the batch’s activities is a priority, the module makes available a dedicated reporting functionality that allows to select the contract, the company and the time period, and to show the number of activities that company is responsible for on the selected contract, and of these determine the percentage of activities performed or canceled, or not performed due to failure. For activities performed with failure, depending on the reason for the failure, the percentage of work is shown.

[0388] Campaigns are often characterized by a large number of activities that need to be generated and assigned in a very short time, the campaign management module allows to identify, generate and assign hundreds of thousands of activities in a matter of hours.

[0389] This functionality for managing mass work order campaigns, including the mass replacement of meters, is a peculiarity of the Beat system, since it provides complete work management with high emission volumes and a strong need for control by the distribution company. In addition, unlike other traditional Advanced Metering Infrastructure solutions that do not contain modules for managing mass campaigns, or contain dedicated tools that are not integrated with other work management modules, the management within the campaigns within the Work Orders sub-system also allows to manage all the mass activities within the global work management: this allows to provide a unified monitoring and to calibrate the impact of the mass campaigns with respect to the distributor’s normal operations, which consists of higher priority work orders that have be performed as a matter of urgency.

[0390] From a technical point of view, the work order management system contains original characteristics applied in the different phases of a work’s life cycle.

[0391] Enrichment of activity requests and conversion into executable work orders.

[0392] The Work Order Management system acts as a collector of all activity requests coming from the DSO commercial systems and the DSO technical systems (example: field fault management request generation system); in addition, it is able to generate activity requests itself, for types of work for which there is no external requesting system.

[0393] All requests for activities coming from external systems, while being associated with a supply point and therefore a meter, do not contain the technical data related to the meter necessary to perform the work. Having a centralized work management system allows to concentrate all the logics inherent in the association between the activities and the field device, which allow to transform an activity request into a work order executable by one of the two executing systems, that is, the head end system (in case of work that can be performed through remote management) or the WFM system (for work performed on site), in this way, the external systems that generate the requests remain dedicated to their core functionalities without having to gain knowledge of the field devices.

[0394] An activity request provides the type of activity, the measurement point on which it is to be performed and, if necessary, the new contractual and network connection conditions. The Work Order Management system verifies the correctness of the request, its admissibility compared to others and subsequently saves it. For each activity present in the request, it retrieves the contractual and connection information provided in the request, if present, and the contractual and connection conditions retrieved by its local registry data, and also retrieves the data of the meter currently installed at the measurement point. At this point, it performs a series of calculations, defined through appropriate matrices traversed according to the requesting system and the type of activity, which allow to identify:

[0395] • Whether or not the meter is compatible with the contractual and connection data, if it is not, calculate exactly the type of meter to be installed, the number of phases and the voltage of the connection;

[0396] • In the event that the measurement voltage is different from the supply voltage, the number, type, and reduction ratios of the voltage and current reducers that have to be installed in the field are also calculated;

[0397] • Next, the software version of the meter that needs to be installed or reprogrammed, and the button list (sequence of messages to be displayed on the display) that needs to be programmed on the meter are calculated;

[0398] • The status in which the supply will have to be found after carrying out the work;

[0399] • The type of communication provided for the modem, if it is provided for that specific activity;

[0400] • The calculation of the values of the measurement transformers (TA and TV) to be programmed on the electricity meter, if of the industrial type;

[0401] • The power values to be programmed;

[0402] • The meter’s activation dates in case of seasonal supply;

[0403] • The executor of the activity: the remote manager, an operator in the field or if the activity is only administrative.

[0404] All these matrices are implemented on relational DB and exposed by means of REST services to the business logic that manages the different types of requests. To perform all the calculations necessary for each matrix, a configuration table is used for each quantity to be calculated (each matrix can determine one or more quantities), this table will contain, for each type of activity and particular conditions, one or more output values, and there is a REST service, written in Java, which will perform all the calculations with a predefined order, querying the specific tables, and saving the data as the calculations are performed, and performing a roll-back reporting the error in the event that a calculation cannot be performed. Subsequently, the business logic invokes the additional Java functions that allow to assign the activity to the correct module as a function of the chosen executor.

[0405] Performance management during the execution phase (KPI of remote work completion within 4 hours)

[0406] Resolution 87 / 10 / 2017 issued by the Energy Authority establishes that meter programming works have to be managed in compliance with the following KPI: remotely executable activities have to be performed within 4 hours from the moment the request is received. The problem that the Work Order Management system has to solve is to acquire, validate, and create the activities, determine whether or not they can be executed remotely and provide all the data useful for the execution of each activity in the shortest possible time, regardless of the time slot, day and volume of activities that are requested and come from external systems. It was therefore decided to define two architectural modules with different functions:

[0407] • The first one, for the acquisition of the activities, with the task of validating the requests, calculating the data to allow the execution of the activity, defining the executor;

[0408] • The second one, the one managing communications with the remote manager (AMI head end), with the task of defining the activity execution windows, the request message, the management of notifications and the receipt of the execution data.

[0409] The modules are created by a part of process logic and by a part of Java REST services able to be invoked by the processes themselves. The requests, as soon as available, trigger the acquisition process, which performs all the dedicated functions by invoking the appropriate REST services. The REST services access a schema of a dedicated relational DB to guarantee correct entity modelling with data segregation. Communication between one module and the next is mediated by a broker that hosts a queue of trigger messages. Listening on this queue there is a consumer who immediately triggers the process of acquiring the manager managing communication with the remote manager. This process triggers the corresponding REST services and sends the request message to the remote manager. With this particular architecture it is possible to achieve:

[0410] • High parallelism, since the two process modules can work in parallel on the requests for acquisition and communication with the remote manager;

[0411] • Extreme reductions in execution time, since the process logic executes REST calls almost instantly, without creating particular bottlenecks;

[0412] The architecture’s strong points are as follows:

[0413] • Horizontal scalability of process logics, as well as vertical scalability of each instance;

[0414] • Horizontal scalability of REST services, which can be increased or decreased depending on the number of requests;

[0415] • “Micro” BSN logics with access to dedicated schemas to guarantee a high response time independent of the load present. Managing a high volume of work orders: precedence, dependence and overtaking between work orders

[0416] The work order management system centralizes the activity requests coming from the different systems, this is to allow a correct control of the order of execution of the requests, as well as traffic shaping in case of large volumes of incoming requests.

[0417] All activity requests are assessed based on the presence of other concurrent activities at the same measurement point. To do this, a logic of mutual exclusion between processes is created in the acquisition module, in order to adjust the order in which the activities are taken charge of and created. After this phase, there is an admissibility logic and a constraint logic that are fundamental to prevent having inconsistent situations at the level of activities that can be or have been performed. There is a first admissibility table that, for each type of activity requested, indicates what to do if there is an additional open, unexecuted activity in the system. This table indicates whether to reject the incoming request, informing the issuing system accordingly, or to accept it. If the request is accepted, there is a second table of constraints that identifies what relationship exists between the incoming activity and the present one.

[0418] The present activity can:

[0419] • Be created and sent for execution in the field;

[0420] • Request the cancellation of open activities in the system;

[0421] • Be constrained to the execution of the open activity, which means that it has to substantially wait for either the execution or the cancellation of the activity present in the system before it can be processed.

[0422] In the latter situation, there is an additional configuration table, with corresponding control mechanism, which allows to check if an activity performed on a measurement point has another activity previously open but not yet performed. In this case, the configuration table will say whether it is necessary to:

[0423] • Wait for the execution of the open activity;

[0424] • Cancel the open activity since it is no longer needed;

[0425] • Move past the open activity, proceeding with the update of registry data. In this case, the open activity will be recalculated to take advantage of the new data returned by the performed task.

[0426] Thanks to this implementation, for example, the system can manage the concurrence of urgent commercial requests (reconnection of a customer who is in a disconnected state) with respect to mass programming campaigns (e.g. technical reprogramming of hundreds of thousands of devices), and is able to “move forward” the commercial request, even if the technical requests were created earlier, ensuring compliance with the KPIs regardless of the volumes of work in progress and regardless of how many and which systems generate the activity requests.

[0427] Registry data update scenarios downstream of work execution

[0428] The work order management system centralizes the activities that are necessary to allow to have a registry data image of the measurement points managed by an energy distributor which is always aligned and has high-quality data. The type of activities that can be performed, the type of devices and operations that can be performed on them and the data that identify the different entities to be updated are in large numbers and subject to continuous change for technological reasons, because of the working methods of the energy distributor and also due to the new standards issued by the regulatory authority. It therefore becomes essential to have a simple and configurable way to define the updating of registry data. The work order management system solves this problem in the following way:

[0429] • A table of registry data update scenarios is defined that identifies, as a function of the type of activity performed, of the operations performed on the device and of other work execution variables, the list of atomic update services that need to be invoked;

[0430] • Each service is then described by a dedicated table that shows the description and the list of sections that compose it, in the corresponding order in which they have to be provided;

[0431] • There is also a third table present in the relational DB that describes all the sections and uniquely identifies the fields that have to be inserted in this table;

[0432] • There is then a last table present in the Postgres DB that relates the functional fields of a section with the field present in the Hibernate entity of the DB and the way that Hibernate has to use to retrieve it.

[0433] The advantages of such a solution are manifold:

[0434] • With a few simple queries, taking advantage of the execution data, it is possible to obtain the complete list of registry data update services to be invoked for each activity performed;

[0435] • If it is necessary to add a new scenario, a new section or one or more fields of a section, it is sufficient to add one or more configuration rows in the appropriate configuration table;

[0436] • If it is necessary to extend the input parameters to identify a scenario, it is always possible to change the table’s number of columns, modify the existing rules indicating, if necessary, the value for this new parameter and change the code reading mode of the table of the scenarios.

[0437] With this hierarchy of tables it is possible to break down all the hundreds of different registry data update cases according to the type of work performed (new device set up, transfer, replacement due to failure, etc.): since each hierarchical level is a composition of the most atomic level below, the re-use of code is maximized and the risks of implementation error are minimized given the complexity and number of cases to be managed, also allowing to optimize the update logic in order to guarantee speed of execution.

[0438] DATA VERSIONING WITH BITEMPORALISM TECHNIQUE

[0439] Bitemporalism, represented by the pairs of reference start and end dates, and validity start and end dates, which are associated with each version of an entity, is a data historicization system that allows to record the evolution or remediation of a datum, without losing the previous value and the period of time for which it was valid. Each version of an entity has two groups of dates: reference start and end dates, and validity start and end dates. The former track changes to an entity determined by the processes performed, while the latter track changes to the entity registration within the master data management system. The mechanism described in general above will be explained below with reference to figure 10:

[0440] For example, at moment 1 a meter is installed in the field, on June 11 at 10:00 hours. This installation activity is recorded in the master data management system a few hours later, at 13:00 hours, when the activity done in the field “returns” to the central system. In this way, a version of the metering entity is created with a reference start date of 11 June at 10:00 hours, and a validity start date of 11 June at 13:00 hours. The validity end and reference end dates are both valued at plus infinity, since there are no later versions of this entity. Subsequent to moment 2, on 20 September at 15:00 hours, with a remediation, the contractual power of this meter entity is adjusted, going from 3 kW to 4.5 kW, because the meter had been installed at the beginning with 4.5 kW contractual power but, due to human error, an incorrect power value had been entered in the outcome of the work order: this will result in the creation of a new version of the entity with a validity start date of 20 September at 15:00 hours, and a reference start date of 11 June at 15:00 hours minus 1 second. The previous version will be updated and invalidated, setting a validity end date of 20 September at 15:00 hours minus 1 second. Subsequently, at moment 3 on the 14 December at 08:00 hours, by means of a work order, the active rate on the meter is changed, changing from rate X to rate Y; the change is recorded in the system at 11 :00 hours on the same day: this determines the creation of a new version, the same as the current one but with a validity end date of 14 December at 11 :00 hours minus 1 second, the modification of the current version of the entity by setting the reference end date to 14 December at 08:00 hours minus 1 second, and the creation of a new version of the entity with a reference start date of 14 December at 08:00 hours and a reference end date of plus infinity, validity start date of 14 December at 11 :00 hours and a validity end date of plus infinity. This means that at the end of these changes there are a total of four versions of the entity, of which two versions “correctly reported” from the point of view of the distributor’s processes, relating to the meter entity, one with a period from 11 June to 14 December, and one from 14 December onward. There are then two versions that are no longer valid, the one with incorrect contractual power created first and the one with contractual power for the reference period that is no longer correct, which remain tracked in the system for historical reasons or for the management of disputes with customers, but which are not used for the purposes of processing the distributor’s processes. Figure 11 summarizes the example of using bitemporalism described above. The architecture of the sub-system is such as to allow to create an arbitrary number of versions for entities consisting of tens of millions of records with historical depth spanning beyond 10 years.

[0441] Bitemporalism also finds a very effective application in the context of managing measurements, in particular in the different entities that contain the measurement datum.

[0442] An example of such use could be monthly consumption, in which the “reference period” coincides with the month of the measurement. Figure 11 shows the example:

[0443] Let us assume that for customer X the real consumption for the month of December 2023 is not available because the meter is not reachable and does not provide the central system with the real value.

[0444] According to the timing dictated by the billing process, the measurement system has to make the energy of all customers available within a specific day and therefore, for example, on 08 / 01 / 2024 at 10:00:00 hours, the system estimates the value 10 for the measurement of the month of December 2023 (Month = 202312) and then a line will be created that refers to the month of consumption 202312 with a validity that goes from January 8 at 10:00 hours until infinity. This estimated measurement is sent to the various external systems for invoicing.

[0445] Let us finally assume that on 22 / 1 at 14:00 hours the real measurement arrives with a value 12 which has to replace the estimate. This will result in the creation of a new version of the entity, always referring to the month of December 2023 with a validity start date of 22 January at 14:00 hours. The previous version will be updated and invalidated, setting a validity end date of 22 January at 14:00 hours minus 1 second.

[0446] MULTI-ENVIRONMENT MEASUREMENT FUNCTIONALITY

[0447] The main environment in which the measurement processes operate is the consolidated environment, in which the measurement data that will have to drive all the actual processes, such as invoicing, budgets and export of data to the external systems that need them, are saved. However, there are several functional scenarios for which it is not possible to modify the data directly in the consolidated environment, so as to prevent them from immediately affecting the official processes, but a separate version has to be kept so that it can be used for different functional needs.

[0448] To avoid having to duplicate the code and the functionalities that read and process the data, different versions of the measurement entities have been defined, which differ from each other by a simple prefix or postfix in the name. In this way, the measurement processes will be invoked, always providing a parameter that indicates which version of the measurement entities to work in.

[0449] Assuming that we want to consider the entity that represents the energy withdrawn by a customer, two distinct entities could be created, one that is called for example consolidated energy that represents consolidated consumption, while another that is called temporary energy that represents a temporary consumption.

[0450] The measurement process that calculates the energy can be invoked to perform the calculation in one or the other environment, driving the choice by means of a parameter that indicates which of the n environments to use to find the data to be used in the calculation, and where to possibly save the result of the calculation itself.

[0451] A first application of the Multi-Environment can be that relating to changes in the measurements performed by back office operators. Due to the complexity of the measurement data and the criticality of the datum (which determines the billing thereof) it is not possible to run the risk of changing the measurements without being able to carry out a complete control of the effects of the change before the change results in a new billing.

[0452] To do this, when a back office operator accesses a supply, the screen automatically displays the data present in the consolidated environment.

[0453] When the user decides to change a measurement datum, a temporary measurement environment temporary * is populated, which contains all the data present in that instant in the consolidated environment.

[0454] By doing this, the screen will start to display the data of the temporary environment. The operator will then perform the actions that re able to modify the measurement datum, and these actions will drive the back end processes, indicating precisely the need to work with the temporary data.

[0455] When the user has finished the work, they will be able to view the effects of the changes on all the measurement entities, displaying different graphs and tables on the screen.

[0456] When the operator has certified that the effect of the changes made is consistent with what expected, they will confirm the changes.

[0457] After their confirmation:

[0458] • The rows changed in the temporary * entities will update the consolidated * entities;

[0459] • The rows present in the temporary * entities will be deleted.

[0460] From that moment onward, the screens will once again display the data of the consolidated environment for that operator.

[0461] A second application of Multi -Environment is that relating to the management of the parallel environment.

[0462] This environment becomes necessary when operators become aware that the actual acquired and invoiced measurements of a supply have been distorted, either by a meter anomaly or due to fraud by a customer, who may have tampered with the meter. In both cases, the invoiced measurements do not correspond to the actual measurements, and therefore it is necessary to start the reconstruction process, which has the task of determining the real value of the energy to be invoiced. In this scenario, it is not correct to continue acquiring and invoicing untrue measurements, but it is also necessary to continue acquiring the measurements detected by the meters. In order to do this, when the inconsistency between the measurements of the meters and the actual consumption of the customers is detected, the parallel environment is opened, which consists in copying all the measurement data in the parallel * entities and tracing the beginning of the measurement reconstruction process.

[0463] From the moment when the beginning of the reconstruction process is tracked for a supply, then:

[0464] • All real data are acquired and validated in the parallel environment;

[0465] • Acquired data will no longer enter the consolidated environment, but billing will be guaranteed by the estimation processes;

[0466] • The operator who has to perform the reconstruction may decide to display on the screen the data from both the consolidated environment and also the parallel environment.

[0467] The operator will carry out the reconstruction, and the reconstructed data will go to a further measurement environment that is saved in the reconstruction * entities.

[0468] Once the operator has completed the reconstruction process, then:

[0469] • The changes made in the reconstruction * entities will be saved to the parallel * entities;

[0470] • Subsequently, the parallel * entities will be saved in the consolidated * environment;

[0471] • The parallel * entities will be deleted;

[0472] • The end of the reconstruction process is traced;

[0473] • The invoiced values will be adjusted, resulting in the adjustment of invoices to the end customer.

[0474] From that moment onward, since the reconstruction process is closed, all the real measurements will be managed in the consolidated environment.

[0475] The application of the measurement Multi-Environment can find uses in other scenarios that are based on the same logic.

[0476] AUTOMATED RECALCULATION AND VALIDATION OF HISTORICAL MEASUREMENTS

[0477] The measurement management system considers all measurement information as interconnected, regardless of the billing period.

[0478] A billing period usually considers a calendar month, and in the vast majority of cases real measurement information is available that delimits the two extremes of the billing periods, in addition to any intermediate measurements.

[0479] For example, assuming the billing period of October 2023 is considered, the billing extremes that determine the energies to be billed are the measurement data of 1stOctober 2023 and those of 1stNovember 2023, in addition to any additional measurement information within that month. The extreme measurements can be either real or estimated, in all possible combinations.

[0480] When the measurement system acquires a new measurement, the latter can determine the calculation (or recalculation) of the measurement in different billing periods. In fact, a measurement that enters the system provides the calculation of all the measurements from the previous real reading and up to the possible subsequent real reading, and in the absence of a subsequent real reading, to the last estimate made.

[0481] The table in figure 20 shows an example of a scenario:

[0482] If a real reading for 1stOctober 2023 were to arrive (for example as a result of work by a user or as a result of a late acquisition by remote management), this reading would determine the recalculation of the billing measurements for the months from August 2023 to November 2023, because:

[0483] The real measurement that precedes the 1stOctober is that of 1stAugust.

[0484] The real measurement that follows the 1stOctober is that of 1stDecember.

[0485] This is shown in row a) of figure 20.

[0486] This means that the system will have to recalculate all measurements from August to November, as shown in the following row b) of figure 20, resulting in billing adjustments.

[0487] If, on the other hand, a real reading for 1stJanuary 2024 were to be received, this reading would determine the recalculation of the billing measurements for the months from December 2023 to January 2024, because:

[0488] • The real measurement that precedes 1stJanuary 2024 is that of 1stDecember 2023.

[0489] • The real measurement that follows 1stJanuary 2024 does not exist, and therefore the last estimate is taken, which is that of 1stFebruary 2024.

[0490] This means that the system will have to recalculate all the measurements from December 2023 to January 2024, including the re-estimation of the reading of 1stFebruary 2024, as represented in the following row c) of figure 20, with consequent billing adjustments.

[0491] “NEAR REAL TIME” MANAGEMENT OF THE MEASUREMENT DATA COLD

[0492] COPY A technological / architectural solution to manage in “near real time” mode the updating of an important amount of data and its changes over time on columnar structures.

[0493] This solution allows to create a cold image updated in “near real time” with the information present in the production databases, allowing to run reports, analytics and access to the datum without directly accessing the production data.

[0494] The architectural solution is based on the concept of Cold image and Data Product.

[0495] The entities managed in the HBase columnar database are of a very considerable size (PB) and above all have a very high update volume (100+ TB per day, 1+B rows per day), both for new data and also for changes to existing data. One of the main critical issues is what is called the long-tail update; in fact, the measurement data of the last 10-15 years are modified every day, with a queue that decreases in volume the further back in time one goes, but which in any case always touches very old data.

[0496] Figure 20 shows the architecture diagram of the NRTU (Near Real Time Update) software module:

[0497] The schema applies to a store of any Entity whatsoever.

[0498] Beginning with Kafkaproxy (KP), which is a CDC that simulates an HBase cluster, then from HBase the mutations are replicated using its native replication toward this artifact (20.1).

[0499] KP intercepts the mutations, connects to Phoenix metadata, deserializes the data and serializes them in Avro, publishing them on a Kafka topic (20.2). This choice was made to make the mutations agnostic to the technology that produces them, using a common and self-describing format, which can be used even by those who do not know HBase or Phoenix. These topics are subscribed by several processes, some of which are disclosed below.

[0500] In the present case, one of the subscribers of the topics is NRTU-Streaming, which consumes the mutations and appends them (20.3) in a Parquet-s3 structure (Parquetstreaming). This Parquet structure is partitioned by processing date, it contains the data of the HBase table plus ghost control fields that allow to trace the timestamp of the row update.

[0501] Up to this point, all the variations that reach the database are being tracked, but it is necessary to start from a tO containing all the previous data and which will be downloaded only once.

[0502] For this purpose, the software NRTU-Massivelmport is used, which reads a full HBase table, using an HBase snapshot (thus accessing the files directly, without overloading the DB engine).

[0503] Massivelmport reads the files serialized with Phoenix, deserializes them using the metadata as Kafkaproxy does and, in this case, serializes them in Parquet-s3 (20.4).

[0504] The Parquet-compacted table created has a partitioning usually by date, a very common access pattern for analytical accesses. For example, for load curves, measurement and consumption logs, the month to which the measurement belongs is used as the partitioning key, thus allowing to push the filters for access over time ranges. This type of partitioning also facilitates updating the data, which is described below.

[0505] The following describes the update of the image tO with the variations that have arrived. The main challenges are:

[0506] • Significant volumes of data;

[0507] • Long-tail update;

[0508] • Parquet is immutable, making updates is not possible;

[0509] • The management of the Parquet schema by Glue and HiveMetaStore allows to act only at the partition level;

[0510] The task of updating the store is performed by the software NRTU-Compactor, which runs periodically and applies the following logic: a. It takes the variations from Parquet-streaming and performs an optimization process by aggregation (squash). This operation is necessary because Parquet-streaming contains all the variations; therefore, there may be more variations for the same row that are squashed in this step; b. Based on the policies that vary from table to table, depending on its characteristics, it merges the last n partitions of the Parquet-compacted with the data present in Parquet-streaming (20.5a); c. All the Parquet-streaming data left out of step b are saved in a structure called Parquet-remainder (20.5a), which contains all the variations arrived that have not yet been merged into the Parquet-compacted. Parquet-remainder has the same partitioning as Parquet-compacted; d. Based on the policies that vary from table to table, NRTU-Compactor selects the Parquet-remainder partitions that need to be emptied and merges them with the corresponding Parquet-compacted partitions. This step is very important to control the size of the remainder and prevent it from growing too large e. Finally, Compactor saves the result of step a. in another structure called Parquetvariations (20.5b) which contains all the variations aggregated (subjected to the squashing process) and partitioned by processing date (the same as the streaming). This structure has a rolling management (it typically contains the last 7 days of data) and is very useful for those patterns that look for variations, avoiding carrying out important scans back in time in order to read perhaps only a few lines

[0511] The following describes how this data are made available.

[0512] The first output port is the classic cold-image, a cold and consistent image of the store (20.6). It is obtained with a view that creates a merge between Parquet-compacted and Parquet-remainder, selecting, in the case of duplicate rows, the most recent one. This view is out-of-the-box and stops the user from knowing the underlying complexity. Performances are guaranteed by a feature of the main optimizers which is the broadcast join. For a join between a large and a small table, the optimizer decides to broadcast the small table in all the instances that perform the join, in this way the join is very efficient, resolves locally and minimizes the shuffle between the performers. This is the main reason why the Parquet-remainder has to remain small (see step d of the NRTU- Compactor). Since it is a queue of variations that decreases over time, the newer partitions grow considerably (and in fact are immediately merged in step b of the NRTU- Compactor), the older partitions grow little and when they reach a certain size or longevity they are merged (step d of the NRTU-Compactor).

[0513] The second output port allows to read the variations of the last n days (20.7). In practice, it is exactly the content of the structure updated by step e of the NRTU- Compactor, purified from the ghost fields that are not of interest.

[0514] The third output port is a near-real-time view (20.8). It creates a merge between the first output port and the Parquet-streaming current content, allowing to have an image with a lag of a few minutes compared to the operational. This view is the heaviest of all, but is usually used for analysis on a small number of very recent data (typically BI or process monitoring).

[0515] It is clear that modifications and / or additions of parts may be made to the method and system as described heretofore, without thereby departing from the field and scope of the present invention, as defined by the claims.

[0516] It is also clear that, although the present invention has been described with reference to some specific examples, a person of skill in the art will be able to achieve other equivalent forms of method and system, having the characteristics as set forth in the claims and hence all coming within the field of protection defined thereby.

[0517] In the following claims, the sole purpose of the references in brackets is to facilitate their reading and they must not be considered as restrictive factors with regard to the field of protection defined by the claims.

Claims

CLAIMS1. Computer implemented system for managing an electricity distribution network including a so-called smart metering infrastructure, which infrastructure comprises field “smart metering” devices, which in turn include: electrical energy meters provided in correspondence with points of supply of said electrical energy to end users and which points are distributed over a pre-established territory; preferably, so-called concentrators, which are provided in pre-established branch / transformation nodes toward the low voltage lines that connect a pre-established number of meters; said meters and said concentrators being provided with communication units to communicate with each other and said concentrators being provided with a processing unit configured to perform pre- established functions and with a communication unit for communicating with a central management system and wherein said central management system consists of a group of reciprocally independent software systems, each dedicated to the execution of at least one or some specific functionalities, which software are executed by a processing unit comprising at least one processor, preferably a plurality of processors and / or a cloud-type processing unit, said management system being characterized in that each system is created with different technologies, and each is provided with its own data layer which only the corresponding system that owns it can access, and which is optimized based on the functions of said system consisting of specific and unique data of the corresponding system and data common to one or more of the additional systems; said common data present in the data layer of each system consisting of copies of the corresponding data present in the private data layer of a master data management system; in the data layer of each system, only copies of the data common to other systems which are functional to the execution of the functions of said system are stored; said master data management system being configured to perform a common service for said one or more systems and comprises its own private data layer and is configured to perform functions of storing said common data;exclusive functions of modifying said common data; functions of synchronizing the modifications of said common data with the corresponding copies present in the one or more systems.

2. System according to claim 1, wherein each sub-system or at least part of them is associated with certain entities characterized by a set of data and which correspond to certain hardware units comprised in the network structure and / or to certain administrative entities and / or to certain administrative or non-technical functions and / or certain technical functions, and one or more of the said entities can be shared with one or more of said subsystems, these entities being registered with reference to the aforementioned characterization data thereof in a sub-system with master data manager functions, with modifications of said entities being performed within the master data manager sub-system and replicated by it in the form of copies in the other sub-systems that share them.

3. System according to one or more of the previous claims, wherein with reference to entities characterized by data and used by a sub-system, the replica of the said entity present in the data layer of the said sub-system presents only data among those of characterization that are functional to the performance of the activities of the said subsystem, while modifications of these data are transmitted to the master data management sub-system for the modification of the characterization data of the said entity which are managed centrally by the data layer of the said master data management sub-system.

4. System according to one or more of the previous claims, in which sub-systems are provided which provide common services which are selectable from one or more of the sub-systems of the following list: a sub-system with portal functionality which unites all the individual web interfaces of the individual sub-systems generating a single work environment for users, a sub-system for the centralized management of SSO authentication processes and / or AAA protocols for access to individual sub-systems; realtime monitoring sub-system of all sub-systems present, Reporting and analysis subsystem provided to all sub-systems.

5. System according to one or more of the previous claims, wherein the master data management system associates with each entity to which there correspond one or more specific data characterizing said entity, a start instant and an end instant, the instant of the end of the said entity being determined by the instant of recording the data according to the said modifications, a new replication unit of the said entity being automatically generated having a start instant corresponding to the instant of recording the modificationof the said one or more data and there being associated, with the said new replication unit of the said entity, an open or indeterminate end date, each previous and terminated replication unit of the said entity, and each subsequent replication unit of the said entity also terminated or with an undefined end date, being processed and / or stored independently of the others, while all the units of a unit are kept in an archive.

6. System according to one or more of the previous claims, wherein a sub-system for managing technical activities by means of a mobile phone is provided, which sub-system is configured as a suite of applications for mobile units which is executed within one or more of the said units assigned to one or more operational users, the said suite comprising a plurality of applications configured to support field activities and presents a modular architecture, the said apps having some specific technical functionalities and functionalities for managing the concentrators and / or the meters and other apps having functionalities / services that cross-cut the others, said apps being divided into independent apps, each configured by means of corresponding software for the independent execution of specific operational functions on the said concentrators and / or on the said meters, said apps being activatable independently and in parallel to each other by one user or several users.

7. System according to one or more of the previous claims, wherein two separate and independent sub-systems are provided for managing different types of measurement units, one of said sub-systems dedicated to communication by means of concentrators with measurement devices provided in the low voltage network and the another of said subsystems for managing point-to-point communication, each of which sub-systems has a dedicated architecture and a dedicated data layer accessible only to the corresponding sub-system.

8. System according to one or more of the previous claims, wherein each concentrator is connected or connectable to a pre-established number of different meters in correspondence with as many energy withdrawal sites for the transmission / reception of messages containing requests for execution of tasks and / or or measurement data, alternatively or in combination by means of a wired communication line, such as in particular the electrical energy distribution line between the concentrator and a meter associated with it, and by means of wireless or radio frequency type transmission / reception units, the said concentrators and / or the said meters being provided with at least one processing unit with a memory in which a communication program isloaded which contains the instructions to make the said processing unit capable of carrying out the following steps: monitoring the communication functionality toward each of the meters associated with a concentrator through the electrical distribution line and by means of the radio frequency transmission / reception units; using cable communication when transmission by means of radio frequency transmission / reception units is not functional, or vice versa; providing that one or more meters can be associated and / or are associated with at least a second concentrator which is provided with a radio frequency transmission / reception unit, and automatically activating communication by means of the radio frequency transmission / reception units with said at least one further concentrator when the functionality for communicating by means of the electrical energy distribution line and / or by means of the transmission / reception units between said meter and said concentrator with which it was originally associated is compromised or not present.

9. System according to one or more of the previous claims, wherein a communication sub-system is provided which is configured to at least transmit requests to said concentrator, which requests consist of individual independent messages having a pre- established execution deadline and / or a pre-established execution priority, which communication sub-system is configured to generate groups, so-called message consolidation boxes for the contextual transmission of said messages in a consolidated form, each group being configured to consolidate messages with an expiration date within a pre-established time interval, the transmission date of each group being determined as prior to the execution deadline of the messages consolidated into a group and / or prior to the message execution priority date, while messages with execution requests having higher priorities are not consolidated with messages that are less urgent and have expiration dates after the expiration dates of priority requests.

10. System according to one or more of the previous claims, wherein said system comprises an online interfacing sub-system available to authorized users, which subsystem comprises software comprising encoded instructions which when executed by a processor make said processor capable of performing functions of modification and immediate recalculation of all the acquired measurements, this recalculation relies on a data archive which contemplates the acquisition on a daily basis of a pre-established number of samples for each type of energy measured (active, reactive inductive, reactivecapacitive) and such modifications automatically causing consistency recalculations on the consumption profile and reconciliation with the daily closing registers.

11. System according to one or more of the previous claims, wherein said system comprises a problem management module, which module is of the computer implemented type and comprises a program with encoded instructions which when executed by a processor make said processor able to perform the following steps: providing a columnar big-data database, in which data relating to events relating to the functionality of one or more units present in the network are stored, such as in particular the concentrators and / or meters, or other operational units; applying a map-Reduce algorithm to said data to extract information on at least one problem configured by said data; generating a resolution ticket for said at least one problem and transmitting said ticket to an automatic problem management sub-system; said sub-system being configured using a software that encodes the instructions thereof with a core for decoding words or state variables of the said units and in particular of the concentrators and / or meters and especially of the hardware thereof, activating, in the face of error codes found in the execution of the activities, a sequence of corrective actions which can be of a manual or automatic nature by automatically creating or executing remotely SW update activities or technical reprogramming of the said meters and / or concentrators, or by creating and sending to an intervention activity management sub-system requests for activities to replace faulty meters and / or to determine whether an attempt at tampering has been made, communicating the activities to be performed to the remote management system of said units.

12. System according to one or more of the previous claims, wherein a centralized subsystem for the management of automatic and / or manual operations is provided, which sub-system manages all the intervention activities controlled by each of the sub-systems in a synchronized manner with each other.

13. System according to one or more of the previous claims, wherein a sub-system is provided for generating so-called cold copies of the data contained in an HBase columnar database, which sub-system consists of a software with encoded the instructions for executing the following steps, when executed by one or more processors: generating a cold copy of the HBase database in the form of a snapshot of the HBase table in column-oriented data storage format;collecting the variations of one or more data present in the snapshot in the form of messages; executing a fusion of the data present in the copy in column-oriented format with the data variations optionally performing a squashing step; generating a parallel file having the same partitions as the storage file in column- oriented format and containing the variations not yet consolidated because they arrived at subsequent moments and making the data of the modified column-oriented file accessible and in parallel or alternatively also the data of said parallel file.

14. System for managing data relating to one or more different entities characterized by the category or typology of said data and in which the data of the said entities are variable over time with different frequencies from each other, said system comprising a processing unit with a memory in which at least one management program for the said entities is loaded or loadable which consists of or comprises a Master Data Management system comprising in turn instructions for the processing unit which when executed thereby make the said unit capable of executing the following steps:- when one or more data of an entity are subject to a modification, recording the time instant in which said modifications occurred as the instant of termination of said entity and recording the instant in which said modifications occurred as the instant of generation of a new unit of the said terminated entity, and associating with the said new unit of the said entity an instant of open or indefinite termination, while these steps are repeated essentially for each event of modification of one or more data of the said one or more entities or for each of pre-established types of modification events, with all the said terminated units of each of the said entities being kept in an archive.

15. Management system of a distribution network which in turn consists of a combination of purely structural elements, in particular power lines and devices consisting of hardware / software combinations and equipped with functionalities for monitoring operating conditions or measuring the time trends of the quantities supplied and entered, and for storing monitoring and / or measurement data, as well as functionalities for communicating with one or more of said sub-systems, also equipped with calculation capacity (Edge system) and local control capacity (loT, Internet of things) integrated with the modules described in this document and which system comprises one or more of the sub-systems of the following list configured according toone or more of the previous claims: at least one smart metering sub-system for the acquisition of measurement data from measurement devices connected to the low voltage network and / or one smart metering sub-system for the acquisition of measurement data from measurement devices connected to the high and / or medium voltage network; at least one measurement data management sub-system configured to manage all processes after the acquisition of data relating to the measurements and before invoicing; at least one sub-system for generating and managing work orders relating to interventions on the network; at least one sub-system for managing field work order assignment and mobile execution.

16. Management system of an electricity distribution network comprising so-called concentrators and electrical energy withdrawal points, so-called meters or smart meters, wherein a pre-established number of said meters is connected or connectable to a common concentrator, the concentrator being connected to the said management system for the transmission of data, commands or status information to said concentrators and indirectly through the said concentrators to the meters connected or connectable to a concentrator, said concentrator management system being provided with a communication sub-system which is configured to at least transmit requests to said concentrator, which requests consists of individual independent messages having a pre-established execution deadline and / or a pre-established execution priority, which communication sub-system is configured to generate groups, so-called message consolidation boxes for the contextual transmission of said messages in a consolidated form, each group being configured to consolidate messages with an expiration date within a pre-established time interval, the transmission date of each group being determined as prior to the execution deadline of the messages consolidated into a group and / or prior to the message execution priority date, while messages with execution requests having higher priorities are not consolidated with messages that are less urgent and have expiration dates after the expiration dates of priority requests.

17. Management system of an electricity distribution network, which comprises a plurality of so-called concentrators which act as intermediate stations for managing energy consumption meters corresponding to at least one specific withdrawal site for each meter, each of which concentrators is connected o connectable to a pre-establishednumber of different meters in correspondence with as many energy withdrawal sites for the transmission / reception of messages containing requests for the execution of tasks and / or measurement data, each or at least a part of the concentrators and of the associated meters communicate alternatively or in combination by means of a wired communication line, such as in particular the electrical energy distribution line between the concentrator and a meter associated therewith, and by means of wireless or radio frequency transmission / reception units, the said concentrators and / or the said meters being provided with at least one processing unit with a memory in which a communication program is loaded which contains the instructions to make the said processing unit capable of carrying out the following steps: monitoring the communication functionality toward each of the meters associated with a concentrator through the electrical distribution line and by means of the radio frequency transmission / reception units; using cable communication when transmission by means of the radio frequency transmission / reception units is not functional, or vice versa, providing that at least one second concentrator, which is provided with a radio frequency transmission / reception unit, is associated or can be associated alternatively with one or more meters which are mainly associated with a different first concentrator, and automatically activating communication by means of the radio frequency transmission / reception unit with said second concentrator when the functionality for communicating by means of the electrical energy distribution line and by means of the transmission / reception units between said meter and said first concentrator is compromised or not present.

18. Management system of an electricity distribution network comprising at least two different types of consumption measurement devices which communicate respectively indirectly by means of concentrator devices with the management system or by means of point-to-point connection with the said management system and in which there are provided two separate and independent sub-systems for managing different types of measurement units.

19. Management system of an electricity distribution network comprising communication interfaces for communicating with mobile units, such as mobile phones or other portable devices, and in combination a sub-system which constitutes a suite of mobile applications, which suite comprises a plurality of apps which are independent ofeach other and each of which it is configured to perform one or more specific business functions and other apps having functionalities / services that cross-cut the others.

20. System for managing data relating to one or more different entities characterized by the category or typology of the said data and wherein the data of the said entities are variable over time with different frequencies from each other, said system comprising a processing unit with a memory in which at least one management program for the said entities is loaded or loadable which consists of or comprises a Master Data Management system comprising in turn instructions for the processing unit which when executed thereby make the said unit capable of executing the following steps:- when one or more data of an entity are subject to a modification, recording the time instant in which said modifications occurred as the instant of termination of said entity and recording the instant in which said modifications occurred as the instant of generation of a new unit of the said terminated entity, and associating with the said new unit of the said entity an instant of open or indefinite termination, while these steps are repeated essentially for each event of modification of one or more data of the said one or more entities or for each of pre-established types of modification events, with all the said terminated units of each of the said entities being kept in an archive.

21. Computer implemented method for managing an electricity distribution network comprising a so-called smart metering infrastructure and which infrastructure comprises field “smart metering” devices, which in turn include: electrical energy meters provided in correspondence with points of supply of said electrical energy to end users and which points are distributed over a pre-established territory; preferably, so-called concentrators, which are provided in pre-established branch / transformation nodes toward the low voltage lines that connect a pre-established number of meters; said meters and said concentrators being provided with communication units to communicate with each other and said concentrators being provided with a processing unit configured to perform pre- established functions and with a communication unit for communicating with a central management system and wherein said central management system comprises at least one data layer for storing the data acquired through measurements on the network and wherein a sub-systemis provided for generating so-called cold copies of the data contained in an HBase columnar database, which sub-system consists of a software in which the instructions for executing the following steps are encoded, when executed by one or more processors: generating a cold copy of the HBase database in the form of a snapshot of the HBase table in column-oriented data storage format; collecting variations of one or more data present in the snapshot in the form of messages; executing a fusion of the data present in the copy in column-oriented format with the data variations optionally performing a squashing step; generating a parallel file having the same partitions as the storage file in column- oriented format and containing the variations not yet subjected to merging, because they arrived at subsequent moments and making the data of the modified column-oriented file accessible and in parallel or alternatively also the data of said parallel file.

Images